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.

Segment.com - Attribution Journey

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.

Entry Condition - Page Load

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

Journey Published

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