Day 10 - Six months later
The code has been running over half a year, quick retrospective
🔗Good
- Works well for identified users
- Super stable (no maintenance/always works)
- Data appears in upstream segment.com sources (mixpanel)
- Most reports make use of the user traits (and not the `Visitor Source Identified` event)
🔗Bad
- Attribution has not been solved for anonymous users (90% of the traffic)
- No fix for ad blockers. % traffic with ad blockers is increasing (safari update, Brave, Firefox)
- most of the packages I used are complaining over deprecated config/changes in how they do things
- We're not using Hubspot anymore. Code was not stable enough either as some API calls failed.
🔗Going forward
We now have a segment.com personas in our subscription and I am wondering if that can replace parts of the solution? Specifically the 'journey' product they recently launched.
The advantage would be that the workflow in segment.com (making use of personas > journey) does support anonymous workflows.
🔗Replace Customer.io hook with Segment Journey
Let's start by creating a journey that calls a webhook on every page load. We don't want to trigger the webhook too fast leaving the SMA lambda to process and identify that user.
Make sure to check the 'include anonymous users' flag. I have opted to trigger the workflow once every 4 hours on a page view. We can tune the exit/entry conditions later.
After the five minutes segment will trigger a send to destination step which I have configured to trigger a webhook. As we can't control the method/format of the payload we need to create a new serverless function that can deal with that POST request.
The code to process the payload looks a lot like the POST request to store page and identify events
Lines 21-22 are a check to make sure it's this specific workflow triggering the event.
​​
​To code accepts events and triggers the right identify() call based on the type of user (anonymous vs identified).
Give it a quick 'sls deploy' and note down the endpoint to create the webhook in segment.com destination. After doing that I published the Journey
Notice that only future visitors will get the attribution data. To solve this I have created a few temporary (one time) journeys to fill in the data for specific segments I was interested in like everyone that visited pricing, last 30 days visitors and a few more.
Note that if you want to fill in attribution data for longer back it will increase your segment bill and any other data destinations that have some kind of MTU based pricing.
🔗Remove Hubspot endpoint
On day 8 we wrote code to pull in sales data. As we got rid of Hubspot as a CRM a while back it was time to get rid of that code.
The reason we removed Hubspot from our stack? Their website javascript was bloated and we felt we weren't using it to the fullest. If you really want Hubspot to work with Segment.com (feeding events etc...) it's really expensive 💵.
I removed references to Hubspot in this commit.
In the upcoming days (day 11 or day 12) I will update the code to reactivate the mechanism where we pull in sales information (customer won/lost, quality of lead) into the attribution project.
The code used in this blog post is available on github.
Â
Other articles in the series
05/07/2021
Day 11 - Sales Attribution
03/07/2021
Day 10 - Six months later
03/06/2020
Day 9 - Dealing with tracking/ad blockers
18/05/2020
Day 8 - Feeding in sales data
06/05/2020
Day 7 - Reporting on visitor sources
01/05/2020
Day 6 - Feeding source attribution data back to Segment.com
27/04/2020
Day 5 - Feed old events
24/04/2020
Day 4 - Run in production + API
22/04/2020
Day 3 - Cleanup & Identify Visitor Source
21/04/2020
Day 2 - Capture segment events
20/04/2020
Day 1 - The Masterplan
19/04/2020
Solving marketing attribution (using segment)