Difference between Data Client ID and Stape User ID

I am testing webhooks with sGTM. I see that by default a “client_id” is generated on each request (via cookie), which is referring to the Data Client ID. I have also enabled the power-up of Stape User ID. These are the two formats that I am seeing:

  • Data Client ID (client_id): dcid.1.1714481809622.426939670
  • Stape User ID (x-stape-user-id): 46e0e1ee94649918e4cc64fcf79d1888

What is the difference between these 2 variables? In which situations would we want to use one over the other? Does it make sense to use both variables?

As far as I understand, the Data Client ID is constructed with the unix timestamp and a random number. And the Stape User ID is constructed by the hashed combination of User IP, User Agent, TLS settings and Hostname.

As far as I understand, the Data Client ID is constructed with the unix timestamp and a random number. And the Stape User ID is constructed by the hashed combination of User IP, User Agent, TLS settings and Hostname.

precisely so. Usage depends on your objective, given it’s webhook we’re talking about - both seem irrelevant in most cases.

Well, I think for a webhook setup where we will receive a GET request for a Purchase event with minimal data (user id & purchase amount) and enrich this data with the data stored in Stape Store (from previous user events), it is crucial to have a user identifier, right? Or am I missing something here?

I think x-stape-user-id is only available in GTM-s, so if you are sending the event_id from both web and server it would be different right?

@hustleou I still don’t think either is useful for you in a webhooks scenario, you should use something solid for ‘stitching’ such as customer’s email or your internal user_id.

@Chris_Bradley you can return the value of x-stape-user-id (or any other piece of data on the server) back to the web IF you need to, just FYI :slight_smile:

Didn’t even think of that. Never send it the other way before, any docs on how to do that?

@Chris_Bradley sure, see here: Send dataLayer push from server GTM to web GTM - Stape

@Dan Thanks, thats epic. super useful and I can definitely see the value of that…

What is the difference then of using my internal “user_id” vs Stape User ID? I don’t see any difference here.

your internal user_id is persistent (that is if it’s an actual user id). Stape’s User ID is a combination of variables that can easily change.

Stape User ID can change if the user changes devices or browsers for example. While the IP is the same, the User Agent will change, and therefore the Stape User ID will change.

But then if I use some sort of internal “user_id”, how can I track this user across different devices or browsers? How is the user_id persistent in this case? (if there is no logged users)

‘internal user_id’ is usually assumed to be an actual id of the logged in user, if that’s not the case - there’s no dramatic difference between the two, as you’ve figured it out already

1 Like

And in regards to the X-Stape-User-Id Request Header, which is the one that we will be using: https://help.stape.io/hc/en-us/articles/12353853307677-User-ID-power-up - It is mentioned that it is constructed with User IP, User Agent, TLS settings and Hostname.

But to what exact headers parameters (names) are these referring to? For example, for the User IP, which one does it use?

  • Cf-Connecting-Ip
  • X-Forwarded-For
  • X-Geo-Ipaddress

I have Cloudflare as CDN (instead of Stape CDN in my container) and each one of these 3 request headers has a different value. The correct one in this case is “Cf-Connecting-Ip”. I wonder if the X-Stape-User-Id in this situation is actually being built correctly.

@Dan any insights about which IP variable is grabbing?

@hustleou Real IP is used, determined by this API APIs für serverseitiges Tagging  |  Google Tag Manager - Server-side  |  Google for Developers

Ok, got it! Then the only way to make the X-Stape-User-Id consistent is to use the Stape CDN. Because if I use Cloudflare, probably the Real IP will not be grabbed correctly, as in the “X-Forwarded-For” header, it is showing a different IP than the Real IP.

API I linked is not looking only X-Forwarded-For, it will try to get Remote IP Address.

Note: this API makes a best-effort attempt to discover the originating IP, but it cannot guarantee that the result is accurate.

1 Like