This week, we will feature two guest blog posts from our Data Analytics Program Manager, Dustin Lester, covering his work with the Automotive Standards Council that was presented at the Modern Retailing Conference in Palm Beach, FL, Nov. 13-15.
Today in Part 1 of Dustin’s blog takeover, he will give some context and history to Google Analytics 4 and the ASC’s work. In Part 2 tomorrow, Dustin will cover how this all applies to vendors and best practices going forward. You can see a full length video of the ASC GA4 specs presentation at the bottom of this post.
History
When DealerOn caught wind of a group attempting to standardize data analytics for the auto industry, I jumped at the opportunity. We became founding members of the Automotive Standards Council, which I will refer to by its acronym ASC, and I began working with other leading Automotive companies to standardize events in preparation for the new Google Analytics 4 update. My team and I had already designed a framework for the new event-based analytics model, which was presented, and quickly adopted by the council where it differed from their first draft.
Over several months I worked to fine tune and modify our language, events, and data points, to ensure the first version of the specification could be used by Auto, and Auto-adjacent companies alike. I am excited that it is now ready for the public, and a free copy of the specification can be found here:
https://automotivestandardscouncil.com/specification/
What’s New in GA4
Fundamentally, GA4 is Event based and the old Universal Analytics was Session based. Sessions become just another event in the list. No longer will you be limited by secondary dimensions, or the pre-built Category, Action, Label, Value structure of Universal Analytics. The ASC spec was written with this newfound freedom in mind, and I took full advantage of the vast amounts of data ready to be unlocked.
Organization
In addition to the Event-based model, there is a new account structure in place, with some substantial changes that we can take full advantage of.
- Properties can now have sub-properties! Google calls these Roll-up Properties. I could go into detail about the amazing things this unlocks, but that will have to wait, for now just know that if website provider or add-on vendors use the ASC spec, you can combine multiple site data streams into a single property, which will let your actual compare apples to apples, instead of apples to bowling balls.
- Views are no more! Gone are the days of having a view for every vendor, with filters and goals you must manage. Google has streamlined everything into what they call “Data Streams”. These are your sources of data, be it from an app or a website, and they are the new source of truth. With this change, however, comes more strict controls around what we can and cannot do. We cannot add custom events or filters when requested and have a clean backup available like we did in the old multi-View ecosystem. Instead, you will start to see more vendor and dealer-specific property utilized.
- Lastly, Tracking ID’s which were synonymous with a Property ID, have been replaced by “Measurement ID” which will be used in tagging and reporting. This is not to be confused with the “Stream ID” which is only a unique identifier of the Data Stream. Google has made this simple to remember, just look for an ID starting with “G-” which will replace the “UA-” ID’s of old.
User Properties and Event Parameters
With the GA4 switch you might run across User Properties, and Parameters more often. Both were used in UA, but the ASC spec takes full advantage of them, so here is a crash course in both. First, their definitions from Google:
User Properties:
User properties are attributes that describe groups of your user base, such as their language preferences or geographic locations. You can use user properties to define audiences. Analytics automatically logs some user properties.
Event Parameters:
Parameters provide additional information about the ways users interact with your website. For example, when someone views a product you sell, you can include parameters that describe the product they viewed, such as the name, category, and price. The automatically collected and enhanced measurement events include parameters by default.
The ASC Spec utilizes User Properties any time there is a high-level datapoint that needs to belong to the user. It is also used as a key for the roll-up properties I spoke of earlier. For example, the custom user property ‘oem_brand’ can be used to segment every user event over multiple sites inside of a roll-up property. No need to open multiple properties to compare the data!
Other useful User Properties we have added include:
- store_name
- oem_code
- user_type
- user_id
- secondary_id
- secondary_id_provider
In addition to these I have added a few extra special DealerOn-only User Properties, which we encourage other council members to adopt in upcoming specification changes.
- website_industry
Which can be extremely useful when your Dealership spans Auto and Auto adjacent industries like RV’s or Motorsports.
- website_id
Which is your DealerOn given ‘Dealer ID’ and can be used to match existing reports.
Why Words Matter
Austin Bekken, our BI analyst, and I spent a great deal of time thinking through and lobbying the council on word choice. With so many vendors and possible adjacent industries to keep in mind, we had to use a common language. Google themselves stress this in their word choice and name recommendations. Therefore, you will not see the word “vehicle” used. Instead, you will see “item or items.” This allows for Parts Websites, RV’s, Motor sports, and more to all use the same term. Language that was not the same across website vendors was also standardized.
Ready to supercharge your SEO?
Schedule a demo and we’ll show you how!
You no longer need to juggle VDP (Vehicle Details Page) vs VLP (Vehicle Listings Page) when comparing reports, it will simply be an “item page,” and your SRP (Search Results Page) or MRP (Model Research Page) will be an “item listings page.” Reusability was also top of mind when selecting our words. Instead of making events for every widget and tool combination, a web “element” can be used. Thus, reducing the overall number of unique events.
Instead of making unique events for clicks, swipes, hovers, or views interactions. The words “engagement” or “interaction” was used, and a parameter of “event_action” put in its place. Another example would be the combination of videos, 3d viewers, and images into “media”.
Austin Bekken, our BI analyst, and I spent a great deal of time thinking through and lobbying the council on word choice. With so many vendors and possible adjacent industries to keep in mind, we had to use a common language
The Power of Parameters
I have been talking a lot, let’s see some examples. In Universal Analytics, we had 3 main data points for events: Category, Action, and Label.
In this example we have a user clicking on a call to action:
- The Event category, which was often inconsistent across web providers and third parties. It might have included a product name or vendor.
- The Event Action was often the name of the event, or in some cases, used to pass a more important datapoint such as the URL for Page Level event reporting.
- As web providers we often “hacked” the Event label to have multiple datapoints appending or smashed together to maximize value, which later had to be parsed out.
These limited the types of reports and insights that could be easily gathered. But with ASC GA4 Events you get the same data points and so much more. You will be able to segment your events by:
- Who generated them
- What type of page they were on
- How the event was triggered
- The customer experiences the event resulted in
You will be able to understand more about the call to action itself right out of the gate with element text, order, and color information. When an item is involved, you will have access to a huge “item block” which opens VIN level reporting through the item_id parameter.
In addition to what is shown here, you still get all the rich, automatically generated user parameters such as Medium, Source, and Demographic details. Overall, you might have over 50 data points to play with, per event! With this level of granularity, CTA A/B testing, Vin level reporting, and Vendor comparison reports are possible right out of the gate.
Total Event Coverage
Every event that can happen on a page is covered in the ASC specification, while maintaining a minimal number of unique events. In addition, DealerOn has two more main events that track event interactions, we hope to see adopted as well:
- do_nav_interaction
Which will cover navigation events that happen outside the already established asc_menu_interaction.
- do_element_displayed
Which will cover situations when knowing if an element rendered based on a user’s browser or plugin blockers is important to track.
You will notice the ASC Specification has many events for conversions. This was one of the only caveats to our minimalist mentality. The reason for this is simple; digital advertising’s signals are difficult to manage, and having signals rely on parameter and event values is time consuming to set up across many websites. Therefore, to make using these powerful automated tool events easier, The Council has decided to break out sales and service conversions separately, as well as appointment and non-appointment conversions. This allows automation to signal, not just on a conversion, but an actual sales conversion, while filtering our service conversions that would otherwise negatively impact the algorithms.
A full list of all events can be found in the ASC specification document or can be found in our DealerOn GA4 vendor integration documents, which have the full ASC spec, plus a handful of additions.
