The Problem: Companies use Google, Linkedin, Facebook, Bing, etc. concurrently to drive users to their websites. They deploy ad sources' pixels to measure the performance of respective campaigns. Usually, a user discovers and revisits a website via multiple ad sources before buying a product or service. Given the nature of a user's complex journey when a CTA [call-to-action] occurs, all ad sources involved in bringing the customer to the website take credit[in most cases].
Disadvantages of this setup are -
One purchase or conversion is recorded as more than one; in some cases more than three [by various siloed ad sources].
Massive data leak between systems
Poor decision-making in funding new ad campaigns
False sense of understanding a company's marketing analytics
Unable to tie a customer's email to the ad copy that convinced the person to buy
The negative impacts of this setup are -
When the company finds out about its poor tracking mechanism it would have lost thousands if not millions of dollars on wrong ad placements.
The company would have missed out on a lot of good customers.
The company would have upset a lot of the general audience due to bad ad targeting
Analyze.Agency's Recommendation:
When a user buys a t-shirt or a movie subscription in your company, as the point person in the company you should be able to tell
This person's email id or phone number or both
This person's device info [user agent]
This person's location
The ad copy(s) / campaign(s) that introduced the person to your system
The ad copy(s) / campaign(s) that convinced the person to buy your products
All things mentioned above should happen on a 1:1 basis and not as redacted aggregates [Our recommendation goes beyond Google Analytics].
Analyze.Agency's Solution:
Our solution involves cutting-edge data architecture that has a lot of moving parts. If deployed accurately it can scale to handle millions of users and billions of transactions.
Our solution is already battle-tested by startups in San Francisco and New York multiple times. We have broken down our solution into 5 phases and they are as follows.
Phase-1 Implementation:
All ads that are directed toward your landing page need to have UTM parameters
UTM parameters need to be as descriptive as possibly
https://spotify.com/?
utm_source=google&
utm_medium=banner&
utm_campaign=new_year_offer&
utm_term=taylor_swift&
utm_content=blank_space_tourThe above ad link tells us that a Google banner ad was displayed and it had a new year's offer with Taylor Swift based content in it.
Phase-2 Implementation:
In order to capture visits by anonymous, identified users a CDP tool needs to be deployed on your website/ecosystem.
A CDP tool captures
Current URL & referrer URL
User device info & ID
Repeated user visits from the same browser
Email/phone number when shared by the user
Our go-to CDPs are Segment.com and Rudderstack.com. We have procured and implemented them multiple times. We have personally seen these tools scale to handle millions of users and billions of transactions.
Overall architecture looks like the following.
Phase-3 Implementation:
Your production database is the source of truth for purchases, churn, active users, etc.
Pulling data from a live database is not advisable. Therefore a clone of the prod database needs to be made [with low latency]. From the clone database, the data needs to be sent to a data warehouse via an ETL tool.
Our go-to ETL tools are Fivetran and HevoData. We have procured them multiple times and we have moved at least 33 billion rows using them.
Overall architecture looks like the following.
Phase-4 Implementation:
All the click-stream data that was captured by the CDP from your website needs to be routed to your data warehouse.
Ad spend data from ad sources needs to be sent to the data warehouse
By doing this we will be able to connect your production data, click-stream data, and Ad cost data at the data warehouse level.
Click-stream data will tell us where the user came from, which device was used, and what campaign/ad copy brought them to your website
Prod data will tell us what the user bought, the current status of the user, purchase patterns, churn, etc.
Ad spend data will tell us how much dollars was invested to bring a user to the website
Overall architecture looks like the following.
Phase-5 Implementation:
We have all the data we need to tie every single user to the ad campaign/ copy they came from. The device they used, their location, their purchase patterns, their subscription status, etc.
Now, we have to connect all of this data to extract fruitful insights and visualize the same.
To connect all of the data on a 1:1 basis we will be using a declarative language called SQL.
To visualize the output in the form of charts and dashboards we will be connecting a Business Intelligence tool to the Data Warehouse.
Overall architecture looks like the following.
Measuring Cost per Acquisition Technically via SQL:
The SQL query should join
Production data [including time of signup, UTMs present on URL during signup]
Clickstream data [Where the user came from, how many touches the user had etc before CTA]
Spend data [in order to gauge cost per click/ lead/ acquisition etc]
Once this complex SQL query is built Cost per Acquisition and much more can be seen on a per-user basis.
Final Thoughts:
We have personally seen a lot of companies lose millions of dollars because they relied on tools like Google Analytics that report redacted aggregates vs per-user-based metrics.
We sincerely urge you to build a data architecture like the one mentioned above with or without us.
If you need any help with building a data stack like this please reach us at
+91 917 685 7200 [via Telegram]