Measurement Protocol Case: Tracking backend events and offline transactions
HomeBuilderFinder Inc. (totally made up name) approached me in the fall of 2018. I had previously audited their Google Analytics setup and helped them improve their data quality. Now the time had come to step up their whole Analytics game.
The company
The company is currently present in five countries and have around 250,000 monthly users. Their core service is aimed at home owners (also totally made up industry). Whenever home owners need help improving their homes, they visit this website, select the type of work and describe it (in words and pictures).
HomeBuilderFinder Inc. then collects offers from up to three different vendors. Each vendor provide a price including labor and materials. The home owner then selects one vendor to do the job. Directly on the website, a date and time is agreed on between home owner and vendor.
When the job is completed, the vendor opens up a vendor app, marks the job as complete, and HomeBuilderFinder Inc. then receives a commission (let’s say 5%) of the total revenue of the work.
The background
HomeBuilderFinder Inc. has traditionally been extremely focused on the first part of the journey; namely getting home owners to visit the website and to have them request a price. This has been the most important KPI for years. And as such, their whole Analytics setup has been focused on this as well.
They are now shifting towards a more holistic approach to marketing and attribution. In fact, they need to not only measure the acquisition cost and acquisition journeys for that first KPI (home owners who request an offer). They actually need to track the generated commission based revenue and tie that to their marketing efforts.
The challenge
While the whole process seems very easy and straight forward (from a user perspective), it’s - as always - a bit more complicated than that. This is what actually happens:
| Step | Action | Where |
|---|---|---|
| 1 | Home owner visits website (potentially through paid advertising) | Website |
| 2 | Home owner requests an offer | Website |
| 3 | Company validates the request details | Backoffice |
| 4 | Company approves the request | Backoffice |
| 5 | Company sends the request to (nearby) vendors | Backoffice |
| 6 | Vendors submit their offers | App |
| 7 | Company notifies home owner when three offers are ready | Email + Text |
| 8 | Home owner reviews offers and accepts one | Website |
| 9 | Home owner requests a date and time | Website |
| 10 | Vendor approves date and time | App |
| 11 | Vendor does the work | On premise |
| 12 | Home owner approves the work | Website |
| 13 | Vendor marks the job as complete | App |
| 14 | Home owner pays invoice | Online banking |
| 15 | Company is paid | Online banking |
| 16 | Company marks job as complete | Backoffice |
So yeah, there’s quite a bit going on. The main challenge is that a lot of stuff takes place in backoffice processes. So there are no user interactions on the website which can be tracked; most importantly Step 16 which would correspond to the revenue in Google Analytics.
Of course all of those steps/actions are relevant to track, but if we were to select just one KPI it would be the last one - getting paid.
The approach
In fact, the list of actions above wasn’t particular easy to make. No single developer, marketeer or manager actually knew the whole process. So it took a few discovery meetings in order to just map the number and sequence of actions.
In reality, the final list is much longer. The one represented here is heavily simplified. But let’s corner that for now.
Having identified all the actions and where they take place, I proceeded to discuss which backoffice steps should be tracked at all. We basically agreed on steps 4 and 16 as the most important ones (although we later proceeded to include more than those).
From there, I began writing the measurement plan. The plan mostly included user journey examples and technical specifications for dataLayers and Measurement Protocol hits.
The solution
As hinted above, much of the solution was to use Measurement Protocol.