Single post hero image
THE DEALERON BLOG

Standardized Google Analytics Have Arrived: Part 2

By November 17, 2022Google Analytics
Google Analytics 4: What You Need to Know
Google Analytics 4: What You Need to Know

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.

Google Analytics 4: What You Need to Know

Today in Part 2 of our blog takeover, Dustin will cover how ASC spec for GA4 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. You can read Part 1 of the blog here: 

https://www.dealeron.com/blog/standardized-google-analytics-ga4-have-arrived/

For Vendors: What Applies to You? 

Each website provider or vendor does not need to send every event in the spec, they only need to fire the events that apply to their tool or product. If you have a third-party vendor who handles call tracking for example, they will be responsible for sending the asc_voice events. If you have a bolt on digital retailing tool, that sits on top of the site, the web provider would likely not fire these events, but rather the digital retailing tool vendor. 

Reporting First Mindset 

When determining what events to fire, we must keep reporting top of mind. For example, a user tells DealerOn, “I want to know how many button clicks happen site wide.” We must ask ourselves “What would be the best setup to accomplish?” and “What is this button doing?” 

  • Is there a Call-To-Action? Then fire asc_cta_interaction  
  • Do they change pages or tabs? Then fire it might be part of the header nav, so fire asc_menu_interaction or do_nav_interaction 
  • Does it change elements on the site? Then fire asc_element_configuration  

Also, we must consider overlapping events, if a Call-To-Action opens a third-party Retail tool, we would fire the asc_cta_interaction event, and the Retail tool vendor would fire the asc_retail_process event, allowing us to answer the customer question, and allow the Retail tool vendor to capture the start of that user flow in their tool. 

Event Parameters 

The ASC specification outlines 51 custom parameters, and utilizes most default, auto generated, google parameters. I made sure that we were specific in our definitions, formats, and even fallback values if necessary. A full list can be found here (this is a public link I am hosting for ASC, and is open to share):

 https://docs.google.com/spreadsheets/d/1DZLmW9Cp5CA8J1py28xYM6SXRIEeEsagCIIEutjGLeU/edit#gid=0 

You can dive into the details there, but some examples of what you will find include:  

element_color 

  • Definition: Color of the element associated with the event: button, text, object  
  • Formatting: string, hex code  
  • Fallback Value: N/A   
  • Type: Dynamic 
  • Example: #FB0046  

element_position 

  • Definition: Position of the element as it relates to the page or stand-alone modal  
  • Formatting: string, lower case, spaces replaced by _  
  • Fallback Value: unknown  
  • Type: Mapped  
  • Example: center_right 

Formatting here is critical to stick to dynamic values, so everyone is speaking the same common language. Fallback Values are suggested values to send when you cannot identify the data point or cannot map to it. This can be helpful in identifying gaps in our data or troubleshooting mapping.  

Mapped Values 

In the above google sheet, you will see a few are marked “mapped” This means there is a finite list of acceptable values you should send. This will make cross web provider reporting possible, since the event names and parameters will be consistent from vendor to vendor. Its critical followers of the Specification put in the effort to map any internal values to the ones listed. These lists will be one of the main items reviewed and updated in each iteration of the Spec. As more members join, and more use cased for dedicated values are uncovered. Each value may require its own set of logic to produce: 

  • Example for user type, an internal list of dealer IP’s or IP ranges might be used to determine if the user was an instore_customer.  
  • Login creditable might be used to determine client_staff  
  • Department may be combined for your tool or website, Like a Parts AND service page 

You may also note the counsel has chosen to only have 1 item parameter mapped, we recognize the difficulty mapping vehicles and products to a single list of acceptable values could be, as they vary from OEM to OEM, and dealer to dealer. Think F-150, F150, or f150. We hope to get item details in a mapped format in future spec updates, once an agreed upon third party can be found, and adequate mapping logic can be implemented.  

Google Limitations 

I could not go completely wild with dreams of hundreds of data points per event, and endless possibilities of segmentation. Google has some limitations I had to keep in mind. These limitations are less strict for Google Analytics 360 customers, which DealerOn is one of, but we kept the Spec small enough to allow anyone who is not a paying analytics customer to use. I will not bore you with all the limits, but here are the main ones we ran into. 

  • 25 Custom User Properties 
  • 25 Custom Event Parameters 

While not a hard limitation, I had to keep in mind Googles high-cardinality logic. “A dimension is considered high-cardinality when it has more than 500 unique values in one day. High-cardinality dimensions make it more likely that a report hits its row limit, resulting in the “(other)” row. You should use high-cardinality dimensions only for information that’s important and necessary to meet your business goals.” This is why so many of our parameters are mapped, and we hope to map more in coming updates.  

Ready to supercharge your SEO?
Schedule a demo and we’ll show you how!

 

What Can You Do with All This Data? 

So, what does all this data even do? What can you do with all this data? Glad you asked, we can now do the following, out of the box: 

  • Identify and report on flows.
  • AB test based on parameters like element_color , or element_text. 
  • Use event_owner to better understand who is and is not performing. 
  • We can use the department parameter to easily segment events across the site and tools. 
  • Even drop off points become easily found using the comm_status parameter. 

In fact, using your own property, you can make an entire custom event in a few steps. 

  1. Select “Configure” in the lefthand navigation bar 
  2. Click “Create Event” in the right-hand corner  
  3. Name your event, in my example I call it “cust_” for custom 
  4. Select your parameters 

To understand how many forms are being abandoned, it’s as simple as selecting the asc_form_engagment event under the event_name parameter and selecting the comm_status = timeout parameter. Click Create, and you’re done. These are just a tiny fraction of the things you can do with the data!

Implementation 

OK, so you have the spec, and you are a web provider or a third-party vendor, how do you implement it? While the Specification document does a great job outlining how to accomplish this, I want to touch on the main points, most of which were already covered in this post. 

  1. Understand the fundamentals 
  2. Identify what Events apply to your tool or product 
  3. Gather or generate the parameter data 
  4. Fire off the event 

#1 and #2 have been covered above, but for #3, there are two main ways to accomplish this. The first is to generate the parameters yourself, from data you have available inside your tool, product, or page. This will be straight forward and unique to your situation. The second way is by looking inside the asc_datalayer. This data layer operates almost identically to the Google data layer; however, it contains some important datapoints only the web provider or tool owner would know. Some critical data points are: 

  • store_name 
  • oem_code 
  • page_type 
  • measurement_id 

Once you have all the parameters in order, mapped to ASC acceptable values, then it’s the responsibility of each separate vendor (unless other internal agreements have been made) to send the events to EVERY measurement_id listed in the asc_datalayer. This ensures everyone gets this new rich dataset, and the dealerships maintain control over how data flows by choosing to include or ignore measurement_id’s of their choice. 

Final Thoughts 

I am super excited about the spec I have put so much effort into finally being released. I expect you will start to hear more and more talk around it in the coming months, and as the Univeral Analytic sunset date draws closer, which has been pushed back to early 2024. With this pushback, I suspect to see a slower rollout of the ASC spec starting early Q1 2023. Until then, DealerOn has created GA4 Properties for all our clients, and you can find standard events flowing into them today.

Author Dustin Lester

Dustin Lester is the Data Analytics Program Manager at DealerOn. Since 2016, He has developed custom applications and automation for digital advertising, budgeting solutions, and customer reports. In his past roles he has managed the information and data development teams, which handled ETL pipelines, exports, external/internal reporting, and more. Among his many responsibilities, his current role has him architecting, implementing, and managing, enterprise level reports. Dustin scopes and consults on data pipelines changed and maintains most internal data business logic. Dustin is passionate about data acquisition and reporting, with over 10 years of experience in data analytics. He lives in Clearwater, Florida, with his wife and daughter.

More posts by Dustin Lester

Leave a Reply

Call support
(877) 543-4200
Call Sales
(877) 543-6321