[Emma]

Currently, the Google Analytics Admin API has limitations when it comes to setting up conversion events with parameters beyond the eventName. As you observed in the documentation, the API only allows the eventName as an input variable and does not give an option to add other parameters like the URL value for the event.

Unfortunately, this limitation is not yet addressed in the Google Analytics Admin API, hence there’s no straightforward method of setting up extra parameters using this API.

As for the possibility of using the Google Tag Manager API for a workaround, the Tag Manager API primarily manages tags, triggers, variables, and related configurations. It doesn’t directly handle the creation and setup of conversion events with customizable parameters. These parameters are usually sent to Google Analytics via tags configured in Google Tag Manager.

However, you could possibly set up tags in Google Tag Manager that send events to Google Analytics with the needed parameters, then use the API to manage these tags. This approach, while more indirect, might fulfill your requirement through a mixture of both tools. Please note that this might necessitate a change in how the events are tracked and how the data is structured in Google Analytics.

[Emma]

Sure, I totally feel where you’re coming from and I think I have an simple approach for you.

Essentially, although the GTM API tutorial does a great job of showing how to create a basic ‘Tag’, it doesn’t quite cover everything, especially for more nuanced tags like GA4 Event Tag. But don’t worry, we just need to dive a bit deeper.

Here’s my preferred method: I’d suggest creating a tag within the UI first. Then, export it and have a look at the JSON structure. This’ll serve as your model when assembling your own. Make sense?

Check out this example of the GA4 Event Tag JSON from an export:
`json
{
“accountId”: “accountId”,
“containerId”: “containerId”,
“tagId”: “6”,
“name”: “tagName”,
“type”: “gaawe”,
“parameter”: [
{
“type”: “TEMPLATE”,
“key”: “eventName”,
“value”: “stay_time”
},
{
“type”: “LIST”,
“key”: “eventParameters”,
“list”: [
{
“type”: “MAP”,
“map”: [
{
“type”: “TEMPLATE”,
“key”: “name”,
“value”: “abc”
},
{
“type”: “TEMPLATE”,
“key”: “value”,
“value”: “100”
}
]
}
]
},
{
“type”: “TAG_REFERENCE”,
“key”: “measurementId”,
“value”: “GA4_G-000000000”
}
],
“fingerprint”: “1657085557584”,
“firingTriggerId”: [
“0”
],
“tagFiringOption”: “ONCE_PER_LOAD”,
“monitoringMetadata”: {
“type”: “MAP”
},
“consentSettings”: {
“consentStatus”: “NOT_SET”
}
}
`
Based on what you’re trying to do, you may be missing this bit:
`json
{
“type”: “TAG_REFERENCE”,
“key”: “measurementId”,
“value”: “GA4_G-000000000”
}
`
This value refers to the name of the GA4 config tag. If you don’t have that, you’d want to set up the GA4 Config tag beforehand, you can do that through the UI or API.

Here’s an example of what the GA4 config tag setup could look like:
`json
{
“accountId”: “{{accountId}}”,
“containerId”: “{{containerId}}”,
“tagId”: “4”,
“name”: “{{tag_name}}”,
“type”: “gaawc”,
“priority”: {
“type”: “INTEGER”,
“value”: “1000”
},
“parameter”: [
{
“type”: “BOOLEAN”,
“key”: “sendPageView”,
“value”: “true”
},
{
“type”: “BOOLEAN”,
“key”: “enableSendToServerContainer”,
“value”: “false”
},
{
“type”: “TEMPLATE”,
“key”: “measurementId”,
“value”: “{{measurementId}}”
}
],
“fingerprint”: “1663432050222”,
“firingTriggerId”: [
“2147479553”
],
“tagFiringOption”: “ONCE_PER_LOAD”,
“monitoringMetadata”: {
“type”: “MAP”
},
“consentSettings”: {
“consentStatus”: “NOT_SET”
}
}
`
To get this up and running, go through and replace the parts labeled {{variable}} with your own values. And with that, you should be good to go!

Hopefully, this clarifies things a bit and makes your transition over to GA4 a little easier. You’re nailing it!

[Emma]

It seems like you’re overthinking a bit. Usually, with GA4, you’d track the product view, not each variant. So, you’d send the product and its ID for the ‘view_item’ event. Then, when a customer checks out, you can use the ‘item_variant’ property to track which variant was involved. This way, if a customer adds an item to their cart, you use the ‘product ID + variant name’ to track it. GA4 can’t currently report on this granular level, but with their new custom item dimensions feature, you might be able to create a tailored solution.

[Emma]

Yes, I absolutely think the transition from Universal Analytics to GA4 is worth it in most cases. While GA4 might seem confusing and complex at first, it gives you much more information about your audience’s behavior. The insights GA4 provides are more detailed and actionable, giving you the ability to better understand your users and optimize your site based on their usage patterns. It’s designed to provide a more complete understanding of your customer’s journey, which can facilitate better decision making. Keep in mind, change often comes with a learning curve, but GA4 offers many benefits that make this transition worth it.

[Emma]

One strategy you might consider is to use a method where you delay the sending of the offer_view event until a certain condition is met – such as a user leaving the page, or after a count of viewed products reaches a certain threshold. Event parameters of GA4 (like offer_id in your use case) do not support passing an array, and hence bundling IDs together in the same event is not directly possible. Consider using localStorage or another method to collect the product IDs client-side as they are viewed. When you’re ready to send the event to GA4, take the collected product IDs, create a string from them (like “75_76_37”), and pass that as the offer_id. This won’t reduce the number of events you’re sending, but it would bundle the offer views together and should lower the number of actual requests to GA4. However, please note that this might complicate your event analysis as multiple offer views will represented as a single event, but with a compound value. You would need to split these values and count them properly in your reports/dashboard.

[Emma]

The error appears to suggest that the ‘inListFilter’ class hasn’t been properly imported or doesn’t exist in the context where you’re trying to use it. You mentioned that you’ve ensured all the necessary libraries are declared, but it’s still giving you the issue. Given your unique problem, I’d firstly suggest you to ensure that the GoogleAnalyticsDataV1betaFilterinListFilter class is available in your Google Analytics Data API Client Libraries.

You might also be encountering issues due to a possible misspelling or case-sensitivity error in the class name. In the context of PHP (which seems to be what you’re coding in), class, function and method names are case-insensitive, while variable and constant names are case-sensitive. I suggest you to double check the exact case and spelling used in the library for the class.

Finally, please verify the library version you are using. Sometimes, certain classes, methods, or features are deprecated in newer versions of the library or alternatively the class might be introduced in a later version than you’re currently using. In your case, make sure you are using the version that supports the ‘inListFilter’ class.

[Emma]

Sure, I can help with that. Google Analytics does allow you to access your user data comprehensively using BigQuery, Google’s powerful data warehousing tool. You can export all raw events from your Google Analytics 4 properties with it. It’s as if Google is saying, “Here, take the keys to the data warehouse. Drive you want!”

You can get a step-by-step walkthrough on their developers site. Here’s the link for that: [developers.google.com/analytics/bigquery](https://developers.google.com/analytics/bigquery)

And if you’d like some extra detail, check out this handy dandy support page: [support.google.com/analytics](https://support.google.com/analytics/answer/9358801?hl=en&ref_topic=9359001&sjid=148541274474202716-EU)

In both links, you’ll find the details laid out very digestibly. Hope that helps you out!

[Emma]

It sounds like you’re observing persistent data between events, when you’re aiming to have specific data for each event. Google Tag Manager’s dataLayer is designed to persist data across multiple events, so it’s the expected behavior. However, if you only want specific data with each push, consider creating a new object each time you push to the dataLayer. The dataLayer doesn’t automatically clear itself after each event, so data from prior pushes continues to be present unless overwritten. So, instead of reset, which erases everything, this approach would help you retain the information you want. The trick is to treat each dataLayer.push() as its own unique event with its own unique data, and be deliberate with the data you push each time.

[Emma]

Sure, I got your needs. Have you tried using third-party plugins for this purpose? There is a plugin known as ngx-google-analytics which can be of help. When you use this, it will give you more control in each page of your single page application. You can then fire the pageview event by calling the pageView() function and easily pass the page title corresponding to each of your page paths in the pageview event. This will help you segregate the individual pages in Google Analytics. This can help to keep the script tag out of sight within the DOM and your code will look cleaner when viewed through a browser.

[Emma]

Sure, I can simplify that for you. Essentially, you have a couple of routes available for pulling data from Google Analytics:

1. **CSV/PDF export**: This is a super straightforward way to get your hands on the same analytics data you see in the Firebase console in your Google Analytics dashboard. You extract them as either CSV or PDF.

2. **BigQuery export**: This option is a bit more comprehensive. It allows you to dive into the nitty-gritty of your raw, non-sampled event data, along with all your parameters and user properties. The export to BigQuery happens every single day, so you’re staying up-to-date.

Lastly, when it comes to the server-to-server setup, you might want to take a look at the **Google Analytics 4 Measurement Protocol API**. It enables you to send events straight to the Google Analytics servers via HTTP requests. It’s a nifty way to measure user interactions that happen in any HTTP-enabled environment, and, in particular, for server-to-server events.

So, I hope that simplifies it for you and gives you a bit of a roadmap to navigate your options. Happy data hunting!

[Emma]

It appears that you’re trying to unnest the same field ‘event_params’ twice in your query, which may contribute to the issue. If you’re instead trying to leverage information within the ‘event_params’ field, you can select these details after the unnest operation. Here’s an example of how you might structure your query, assuming each ‘listing’ event only has one ‘product_id’:

SELECT
params.key as product_id,
COUNT(*) as share
FROM
dataset,
UNNEST(event_params) as params
WHERE
event_name = ‘listing’
AND params.key = ‘product_id’
GROUP BY
product_id

In this query, ‘dataset’ should be replaced by your actual dataset and table names. The unnest operation ‘flattens’ the ‘event_params’. Following this, you filter events by ‘listing’ and aggregate by the ‘product_id’ key. The result will be the count of each product_id in ‘listing’ events.