Custom Parameter Reporting In Google Analytics: App + Web

In Google Analytics: App + Web, you collect events. One event differs from another event by the name it uses. An event with the name page_view is different from, say, an event with the name file_download.

This is all run-of-the-mill stuff. You know this.

However, the fundamental change that App + Web introduces, when compared to Universal Analytics, is how event parameters are collected and processed.

This gets more complicated than it should be. The complication arises from the fact that there are several components to how App + Web handles event parameters, including:

• Data collection time - limitations on the number of parameters that can be collected with the hit.
• Data processing time - events are processed, and the parameters and their values are shown in the real-time stream views. A maximum of 25 custom parameters included in the hit are made available to reports and the BigQuery Export (assuming you’ve enabled it for your App + Web property).
• Data reporting time - to be able to actually segment and report on these parameters, you need to enable them as custom parameters in your reports. This is the main focus of the article you are reading.

X

The Simmer Newsletter

Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!

Data collection - parameter limit

Google Analytics: App + Web has the same limitation as Google Analytics for Firebase (makes sense, since they share the same technical infrastructure) - you can only send up to 25 custom event parameters per hit. This is in addition to the automatically collected parameters (such as page_location for the page_view event).

For example, here I have a custom event with 26 custom parameters:

When that tag is fired on the web page, all 26 custom parameters are sent with the hit.

In the App + Web reporting interface, only 25 custom parameters are made available. What makes it even more unfortunate is that there doesn’t seem to be a discernible pattern for which parameter is dropped. In the example below, parameter param21 is the one that was dropped.

The next time I dispatched the event, it was param04 that was dropped. It seems to me that the dropping of events is completely random, which is unfortunate. I would have expected an alphabetic sort and truncation from either head or tail of the list.

In any case, you need to be mindful of this. If you want to process the event parameters in the App + Web reporting user interface, you need to make sure to send a maximum of 25 custom event parameters per hit.

Data processing - real time

When you send hits with custom parameters, you’ll be able to see the parameters in real time reports.

The DebugView is a great place to debug the custom parameters. If you’re using Google Tag Manager, entering GTM’s Preview mode will automatically flag App + Web hits as originating from a debug device.

Find your user agent in the Debug Devices list, and then click the event you want to analyze. The parameters will be displayed in one of the DebugView widgets.

You can also see the parameters in the Realtime report (StreamView in Firebase lingo).

Choose Events as the filter, then click the Top Events widget, find your custom event, and expand its parameters.

You can also find the parameters in the All Events report, assuming the events have been collected long enough ago to actually appear in the report. After clicking the event name to enter its dashboard, you can see a Realtime widget where you can choose to filter by parameter name.

As noted before, these are all subject to the 25 parameter limit in data collection. All of the reports in the Google Analytics: App + Web reporting user interface will show you the truncated list.

Data processing - BigQuery export

Once again, I profess my love for Google BigQuery. Enabling the BigQuery export for your Google Analytics: App + Web data is the smartest thing you can do today, so don’t dally!

The BigQuery export gives you the raw data from your App + Web data collection.

It is subject to the same 25 custom parameter limitation per hit as the reporting interface, but you do not have to worry about enabling custom parameters for reporting in BigQuery - all the parameters and their values per hit are collected to BQ.

Data reporting - enabling custom parameters

And now we get to the meat of this article.

Google Analytics: App + Web gives you 50 text parameters and 50 number parameters that you can enable as custom parameters in your reports. That’s per event and per project.

This means that if you want to include your custom parameters in your reports as their own widgets, and if you want to utilize them in the Analysis reports (such as Exploration), you need to first enable these parameters for reporting.

Each time you enable a parameter for an event, you exhaust the quota available for your project. So if you want to use page_location in your custom reports, you need to enable it for the page_view event as a text parameter, and now you have 49 text parameters remaining to enable in your project.

The kicker is that if you enable custom_parameter_01 for an event named my_custom_event, it will exhaust the quota by 1. Then, if you want to use custom_parameter_01 with some other event, e.g. my_other_event, you need to enable it for THAT, too, and it will again exhaust the quota by 1.

These quotas are pretty strict, and I hope they are lifted. If they aren’t, at least you’ll have the BigQuery export to fall back on.

Anyway, to enable custom parameters, you need to go to Events -> All events, and then click the little action menu at the end of the row with the event name.

Note! This means that you need to first collect the event before you can enable parameters for it. Hopefully it will be possible at some point to enable parameters for events that are yet to be collected.

From that menu, choose Edit parameter reporting.

You can always click the Parameter reporting tab on top of the All events report to see a list of the events that have custom parameters enabled, and you can click the event name to edit the parameters.

Once you see the parameter selector, you can search for the parameters name in the list. The list will show all parameters that have been collected with the given event in the date range selected.

If you find the parameter, select it and click ADD.

You can also add a parameter that does not appear in the list. Just type its name in the search field and click Add.

Once you’ve added the parameter, you can set its type, which impacts what you can actually do with the parameter in the reports.

Once you’re happy, click Save to save the changes.

Remember, there is a quota - make your decisions carefully!

Archiving a parameter

When you edit parameters, you can also choose to archive a parameter to free up quota.

Note! If you DO archive a parameter, it is no longer available in the reports. So the change is retroactive - the data will not be recoverable.

The BigQuery export is, again, your best friend, because archiving a parameter will not delete it from the BigQuery tables you have already collected.

Summary

I hope this guide has managed to shed light on how event parameters work in App + Web. The focus was specifically on custom parameters, as they seem to be the biggest source of confusion.

It’s important to rid yourself of the analogy with Custom Dimensions and Custom Metrics in Universal Analytics. Custom reporting in App + Web has fundamental differences to ye olde Google Analytics, particularly in how the same parameter name across different events is treated as a different entity each time, and how archiving a parameter removes it from your collected data, too.

Similarly to Universal Analytics, custom parameters are not retroactive, so they will start collecting data in reports only after being enabled per event.

I’m not sure what to think of custom parameters yet. In the reporting interface they are oddly handicapped with the quotas and the hard-and-fast removal process, but in the BigQuery export they are really valuable.

We’ll see how custom parameters evolve as the beta matures; I think they will play an important part in deciding whether to migrate from Universal Analytics to App + Web.