After creating the SNAP, I was able to dedicate more time into optimising existing processes and one improvement I wanted to make was with the campaign reporting tool.
Problem:
The reporting tool was an email that was sent to stakeholders to show the customer breakdown of a campaign. It was useful for basic counts but it provided the following problems:
It didn't show enough information on customer value, i.e. whether the campaign is targeting low or high value customers
The lack of transparency between the data often led to mistrust between different teams
The display feature we initially used in the report to show the numbers in value segments often required manual changes in the data and the source code when targeting changed. These manual changes were time consuming and led to higher chance of errors
Project Goals:
This project was different to the SNAP but many of the goals remained the same:
Provide accurate counts of customers in different value segments
Reduce the time CRM Data spent on manually changing the data targeting and HTML source codes for daily campaigns
Minimise errors in sharing information between different stakeholders across the business
End Outcome:
Using the findings from the SNAP project, I knew I could create a tool that would a new tool to show customer segmentation value that would satisfy all stakeholders and solve the current problems.
This tool would later be called the RDC and the stages I went through when building this can be seen below:
Approach:
Stage 1: Finding the source code
The initial steps started by having conversations with stakeholders to find what they wanted from campaign reports. I found that they wanted more granular information on customers in different value segments.
Using this, I researched the value segmentation model and how the data is transferred into Adobe Campaign. From there, I was able to find the value segmentation source code and brainstorm ideas of presenting it in the reporting tool.
Stage 2: Creating the JavaScript
After understanding the data model, I wanted to implement value segmentation data as a display table in the campaign report. As I pictured it, the table would provide the number of customers present in each value segment. But for this to work, the counts needed to be referenced using JavaScript.
Using a sample workflow, I ran several tests to see whether the JavaScript written would reference the segmentation data correctly. After prolonged testing, I was able to successfully complete this objective and this can be shown below with both he JavaScript Code and the display log showing the number of customers in each value.
Stage 3: Creating the table
After completing stage 2, I looked to build the table in the reporting tool using the HTML source data. By making the modifications, I created a table that would present separate value bands which would use the JavaScript written already to reference accurate counts. This can be seen below:
Stage 4: Stakeholder feedback
After finalising the initial design above, I presented this to the commercial stakeholders who would use this. Many were happy to be provided granular information, but a growing number found it difficult to read the counts and would mistake it for the wrong value band.
Stage 5: Final Design
This feedback was taken on board and it gave me the idea of differentiating each row by a different colour. By using a HTML Reference editor and CSS, I improved on the existing design as seen below.
This colour scheme was decided as I believed it was easy on the eye and that the shade changes would make users subconsciously aware over time of the different value of each customer. This new design provided much better responses from stakeholders and was a lot more user friendly.
After the new design, the table would later be renamed as the Rainbow Display Count or the RDC.
Benefits:
Creating the RDC accomplished the following:
It provided a more granular level of counts for the value segmentation, improving transparency and leaving less time spent between teams to confirm the correct targeting of a campaign
Removed the rigidity of the old display tool. Previously, changing the data targeting of low value from 1-2 to 1-4 required changes in both the JavaScript and the HTML of the Reporting tool.
The probability for error in campaign execution reduced as less changes were made edit. This was crucial given the high risks involved in the gambling industry.
More people were aware of the different value customers in a campaign, creating another subconscious quality control check and accurate execution of campaigns.
This project provided many benefits for the data team and would later help me with working on other automation projects in the future.
コメント