This article provides you with everything you need to get your page set up with Evolv, so that data about visitors and events will be flowing through to reporting pages, both in the Evolv platform dashboards and Google Analytics.
You'll also learn how to configure GA so that data is consistent between the two platforms. And finally, some methods and examples to validate that agreement.
Note that the below steps start from scratch to set up the project and install the Experience Accelerator. It is also possible that the customer you are working with will already have EA set up. In that case, you can skip step 1.
Also, a mini "A/A test" with fake traffic is described in step 3 to validate the data alignment between Evolv and the customer’s analytics platform. Remember to Leave the "A/A test" running for at least a few days to help spot anomalies.
Steps to integrate and validate Google Analytics
Taxonomy of Evolv Events
Category: All events will have an ‘evolvids’ value so that you can easily distinguish Evolv events in GA from other events set by internal analytics teams.
Action: All ‘confirmed’ and ‘contaminated’ events will fire an action that contains a GID and Ordinal, by default (CIDs and EIDs are optional configurations). However, because Evolv does not have the GID or Ordinal values when the success events fire (e.g. order confirmation, add to cart), event action will just have an ‘evolv-event’ value.
Label: All confirmed, contaminated, and success events (chosen through Evolv Manager) will be included in an event label. Labels consist of three parts: an event description, UID, and SID as seen in the example report above.
How to use Evolv Events
Users in Evolv experiments can be in multiple Candidates at once so we recommend passing Evolv experiment data into events, not Custom Dimensions. This provides a couple of different benefits.
First, events are not subject to reprocessing rules like Custom Dimensions. This is key when a single user can be in multiple Ordinals at one time. So when a user enters multiple Ordinals you’ll have a record of that in Google Analytics, not just the most recent one.
Second, because users can be in multiple Ordinals, you can build segments with Evolv events and apply them to any performance report.
This is what you’ll need to do.
Validating and Reporting on Ordinal or Candidate Traffic
After you’ve validated that event data is flowing into GA correctly, next you will want to make sure that Ordinals (combination numbers) or GIDs (experiment group ID) are showing in the data being received.
To do this, you will need to do two things: create a user-level segment for each Ordinal or GID and filter out contaminated users from your segment.
Contaminated users do not receive the rendered Ordinal variation for various reasons (normally an error), so you do not want to include them in your reporting. Also, when validating against Evolv system data, this will provide the most accurate comparison.
To filter out contaminated users, create a new GA segment that EXCLUDES USERS with Event Label containing “contaminated”.
Use Sessions or Users depending on your project type and reporting needs.
This example using GIDs. You can filter using a combination of the GID and Ordinal if you want to see data for a single combination.
In this scenario, we are making sure that we only include users who were confirmed into a particular experiment group, but did not receive a contaminated event for the same experiment group. The same can be done if using Ordinals.
Once created, apply that segment to any report to filter out contaminated users.
Repeat for any GID or Ordinal traffic you want to analyze.
After your optimization is up and running and real visitor data is flowing through, there are a few situations that can arise that will lead to discrepancies between the two systems. Although there are many reasons why discrepancies between systems may occur, here are a few common ones:
Contaminated Events - If contaminated users in a particular Candidate ID or Ordinal are not filtered out then user counts will be inflated because these users did not actually receive the rendered experience. Evolv does not include contaminated users in platform reporting for this reason.
Clearing User IDs - Although cookie clearing is rare, it is worth mentioning that it can contribute to data discrepancies by creating a new Google Analytics Client ID and/or a new Evolv User ID.
Traffic Filtering - If Google Analytics is configured to filter out internal IP traffic, for example, there will be a discrepancy between Google and Evolv, as Evolv does not filter out traffic except bots.
Session Analysis - Because Evolv targets and analyzes data at the user level, it is a common mistake to look at session-level conversions in Google Analytics (or any digital analytics platform). If you do, you’ll notice data discrepancies between systems. Evolv sends event data to GA when one of two things happen; the user matches the audience and the context predicate defined in the Evolv system, or when a success event (eg. conversion, add to cart) fires, also defined through Evolv. Otherwise, events will not be sent to Google Analytics. So if User A enters an experiment on session one, leaves the site without converting then neither Google Analytics or Evolv would record a conversion for that user. If User A then returns for a second session but does not re-enter the same experiment because they clicked on an ad and entered somewhere else on the website then converted, Google Analytics would not attribute that conversion to an Evolv user but Evolv would. For that reason, we recommend always creating User Level segments in Google Analytics when analyzing Evolv traffic.
Bounces - If users enter the site then bounce before the Evolv GA event fires, it is possible that Google Analytics counts that user in reporting but there is no record of the Evolv event for that user. Users that bounce before the page fully loads may cause discrepancies between systems.
Pre-Candidate or Pre-Ordinal Conversions - Evolv will only count conversions for a user after they have entered an experiment. However, because we’re recommending that you use user level segments in Google Analytics for the most accurate and comparable data, results will very depending on your business. If, for example, User A had two sessions. On session one they visited your website and converted at 8am without ever seeing an Evolv experiment. On session two they visited your website, entered an Evolv experiment and did not convert. Evolv would not count that conversion but Google Analytics would. Here’s why... In the Google Analytics UI, there are no THEN statements so when you’re looking at users who were in a particular Candidate or Ordinal for a particular timeframe, Google Analytics would count conversions for that user if the conversion happened before they entered an Evolv experiment.
Beacons - When data is sent back to Evolv, we use the Beacon API. This has the advantage of not losing the call if the user leaves the page too quickly. GA does not currently do this by default. This can result in Evolv receiving events that GA drops.
A quick note on Candidate/Ordinal reporting…
While this is not a discrepancy issue, how to report on Candidate or Ordinal traffic for a particular Experiment is sometimes misunderstood. Because Evolv runs large scale experiments, it is sometimes thought that the way to analyze experiments is to force rank Candidate IDs or Ordinal values by absolute conversion rate. In fact, the correct way is to always compare the relative performance of an individual CID to control for the time period that it was active.