Google Signal Broke GA4 Server Measurement Protocol 👀!!!

We use Google Analytics 4 (GA4) for user tracking and send certain user events through the GA4 Measurement Protocol using HTTP requests from our servers. However, we suddenly stopped receiving any events for a while. After investigating, we discovered that Google Signals was the cause. BUT HOW?

Yeah, that was exactly my reaction. Let’s dive into how this happened and why.

What was the problem?

First, let me explain how the GA4 Measurement Protocol works. When you set up a data stream in GA4, you can activate an option in the stream settings that provides you with an API secret key. This key allows you to send custom events to GA4 via HTTP requests.

We used an HTTP request like the one below, which triggered an event in GA4, just as you would send events using Tag Manager or other methods (more info here). You can also create sample requests with this GA Event Builder tool.

curl --location 'https://www.google-analytics.com/mp/collect?measurement_id=G-xxxx&api_secret=xxxx' \
--header 'Content-Type: application/json' \
--data '{
  "client_id": "OUR_CUSTOM_UUID_FOR_OUR_USERS",
  "user_id": "OUR_CUSTOM_UUID_FOR_OUR_USERS,

  "non_personalized_ads": false,
  "events": [
    {
      "name": "OUR_EVENT_NAME",
      "params": {
        "PARAMETERS_1": "VALUE",
        "PARAMETERS_2": "VALUE"
      }
    }
  ]
}'

Suddenly, we noticed that events for that specific name were no longer being recorded. This was a very strange issue.

We began investigating, initially thinking that something in our backend code had changed, but there were no modifications. Frustrated, I searched online but found no relevant information. However, I thought that something might have changed in the analytics setup. I checked the GA4 Property Change History (Admin → Property → Property Change History), and found that on the exact date when the events stopped, Google Signals was activated by one of our team members (it’s inactive by default).

How to solve it?

At first, I thought that simply disabling Google Signals would solve the problem. But after disabling it, the issue persisted. I began to dig deeper and found threads like this one, but they were not helpful for our specific case.

I revisited the change history and noticed something important: once you deactivate Google Signals, some settings do not revert. Specifically, the “User-provided-data collection for User-ID” remains active. This change, as seen below, cannot be undone.

This was a new lead. After further research, I discovered that the “user_id” and “client_id” parameters in our event calls were causing the issue. Let me explain.

According to Google documentation for User-ID and Event Payload also this article “Unveil GA4 user insights: User ID, Client ID, and Google signals compared” from LOADER, I understand which because Google Signal is more focused on privacy and can work between a variety of Google Ads tools it’s required to generate its own created user-id to can track better.

According to Google’s documentation on User-ID and Event Payload, as well as this article from Louder, Google Signals prioritizes privacy. It can work across various Google Ads tools and requires its own generated user ID to track users effectively.

Final Solution

To resolve this issue, we updated our HTTP request for event calls by removing the “user_id” parameter, allowing GA4 to generate it automatically. We also sent our custom customer ID through user properties in the event payload, as shown below:

curl --location 'https: //www.google-analytics.com/mp/collect?measurement_id=G-xxxx&api_secret=xxxx' \
--header 'Content-Type: application/json' \
--data '{
  "client_id": "OUR_CUSTOM_UUID_FOR_OUR_USERS",

  "non_personalized_ads": false,
  "user_properties": {
    "domestic_user_id": {
      "value": "OUR_CUSTOM_UUID_FOR_OUR_USERS"
    }
  },
  "events": [
    {
      "name": "OUR_EVENT_NAME",
      "params": {
        "PARAMETERS_1": "VALUE",
        "PARAMETERS_2": "VALUE",
      }
    }
  ]
}'

Hooray! 🎉 Our event records started flowing again.