[Skyler]

Hi Tom,

If you’ve completed all those checks and the set up process was identical to the other successful sites, I’m thinking it might be an issue of data processing time on Google’s end. Usually, events sent to Google Analytics 4 (GA4) should appear almost immediately in the debug view and in the Realtime report. However, owing to different factors, GA might take up to 24-48 hours to process data and reflect it in your reports.

Another thing to check is filtering. There might be some kind of filtering applied that is preventing the events to show. The filter could be at the view level or may have been applied by GA at the property level.

A last resort could be to check if there’s a potential conflict with other scripts on the site. Couple of tools you might find useful for troubleshooting are the “Google Tag Assistant” and “GA Debugger”. They should provide more info on the tags fired and their respective payloads.

If none of these suggestions work, then I’d suggest reaching out to Google’s support via their ‘Help’ portal. I hope you manage to solve this issue soon. Good luck!

[Skyler]

It’s important to distinguish between Google Analytics (the service) and the google-api-php-client (the client library to access Google APIs). The notice you found is about the retirement of Universal Analytics properties in Google Analytics, not about the PHP client library. The client library is just a way to interact with Google’s APIs, including but not necessarily limited to Google Analytics. As long as Google provides updates to the library or it still supports the needed functionalities after changes to Google Analytics, your usage of the google-api-php-client should not take a hit. However, it may require some changes or adjustments in your code when you switch from Universal Analytics to Google Analytics 4. Please stay updated with Google’s official information regarding this transition.

[Skyler]

Hey, no sweat. We’ve got the fix you need. You just need to put the “session_id” inside the “params” array in the event.

Like in this example. It shows you just how your measurement protocol event data should look:

{
 "timestamp_micros": "1664522406546590",
 "non_personalized_ads": false,
 "events": [
  {
   "name": "purchase_balance_top_up",
   "params": {
    "user_id": "11111111",
    "crm_id": "11111111",
    "balance": 990,
    "payment_method": "paymore",
    "session_id": "1664522264"
   }
  }
 ],
 "client_id": "1119492379.1652295143",
 "user_id": "11111111"
}

There you go, problem solved. Keep slinging those APIs!

[Skyler]

Yes, it is true that Safari’s Intelligent Tracking Prevention (ITP) can interfere with Google Analytics because it limits the use of third-party cookies, which are crucial in tracking user behavior. Unfortunately, there’s no easy fix for this considering the restrictions placed by Safari, but some workarounds have been suggested within the analytics community.

A common suggestion is to use first-party cookies instead of third-party ones, as ITP primarily aims to block the latter. There are also ways to implement so-called “cookieless tracking”, although this can get rather technical and may not provide as big a data set as traditional cookie-based tracking.

Another workaround is to use server-side tagging, which means sending analytics data directly from your web server rather than from the user’s browser. Google’s newer analytics software, Google Analytics 4, offers this feature, although it requires a good deal of technical setup.

Remember that the aim of platforms like ITP is to protect user privacy, so any workaround should respect that goal too. It is advisable to follow industry and legal standards relating to privacy and user data. For a complete solution, it might be best to consult with a web developer or digital marketing professional.

[Skyler]

It sounds like Google’s API is not giving the right permissions to properties created through your script. You might be facing a permissions propagation delay, or maybe there’s a bug with the property creation script. A good approach could be comparing detailed settings of a manually created working property and a script-created property, to see if anything comes up differently.

[Skyler]

Sure! So, essentially, you are trying to measure the effectiveness of your Google Ads by reporting certain user actions (like purchases), also known as conversions, back to Google Ads. You’re already tracking these actions in Google Analytics 4 and you’re looking to connect them back to the individual users and the ads they interacted with. To do this, you’re considering using the Google Click Identifier (gclid), a unique code used by Google to keep track of these links.

Including the gclid in your event data would be one way to achieve this. Conceptually, it’s similar to including the user ID you are currently generating in your database. When you report an event, you can include the gclid in your data object and then send it along with your API call to Google Analytics. Google should then be able to use this ID to connect the dots between user actions, your Google Ads, and your Analytics data. Make sure to store the gclid when the user first lands on your webpage from the ad click, and then include it in all subsequent user events.