I am using Google Analytics 4 (GA4) on the client to track a whole bunch of different events. However, there are 2 scenarios that I can't cover client side:
A user completing check out on a payment page hosted by a third-party (Stripe in this case).
A refund that is made by the support team.
These events are handled by the server using webhooks. To me it seems like the most straightforward solution, would be to let the server send the event to GA4 (as opposed to the client sending it). I believe the Measurement Protocol should be used for this.
For each event submitted through the Measurement Protocol a client_id is required. When the client is submitting an event, this is an automatically generated ID which is used to track a particular device.
My question thus is, what should the client_id be when submitting an event server-side?
Should the same client_id perhaps be used for all events, as to recognize the server as one device? I have read some people proposing to use a randomly generated client_id for each event, but this would result in a new user to be recognized for every server-side event...
EDIT:
One of the answers proposes to use the client_id, which is part of the request as a cookie. However, for both examples given above, this cookie is not present as the request is made by a third-party webhook and not by the user.
I could of course store the client_id in the DB, but the refund in the second example is given by the support team. And thus conceptually it feels odd to associate that event with the user's client_id as the client_id is just a way to recognize the user's device? I.e. it is not the user's device which triggered the refund event here.
Another refund event example would be when user A makes a purchase with user B and user B refunds this purchase a week later. In this situation, should the client_id be the one of user A or of user B? Again, it feels odd to use a stored client_id here. Because, what if user A is logged in on two devices? Which client_id should be used here then?
Great question. Yes, your aim to use Measurement Protocol is a proper solution here.
Do not hardcode the client id. It's gonna be a hellish mess in reports. The nature of user-based reporting (which GA is) demands client ids to uniquely identify users. To your best ability.
GA stores the client id in a cookie. You should have convenient and immediate access to it on every client hit to BE. The cookie name is _ga. GA4 appends the measurement id to the cookie name. Here, google's docs on it: https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage But you can easily find it if you inspect "collect" hits and look at their payloads. There's another cookie named _gid that contains a different value. That would be a unique client id. Set it too if you can, but don't use it for the normal client id. It has a different purpose. Here how the cookie looks here, on stack:
And here it is in Network. You will need it for proper debugging. Mostly to make sure your FE client ids are the same as BE client ids:
Keep an eye on the cases when the cookie is not set. When a cookie is not set, that most frequently means the user is using an ad-blocker. Your analysts will still want to know that the transaction happened even if there's a lack of context about the user. You still can track them properly.
3.1 The laziest solution would be giving them an "AnonymousUser" client id and then append a random number to that so that it would
both indicate that a user is anonymous and still make it possible
for GA to separate them.
3.2 A better solution would be for you to make a fingerprint client id for such users, say, hashing a concatenated string of their
useragent+ip+locale+screen resolution, this is up to your analysts
to actually work on the definition of a unique user if the google
analytics library is unable to do it.
3.3 Finally, one of the best solutions for you would be generating a client id on your own, keeping GA's format and maybe adding an indicator there that it has been generated on your end just for easier debugging in the Future and setting it as a cookie, using it instead of _ga. Just use a different cookie name so that ad-blockers wouldn't know to block it.
If you want to indicate that a hit was sent through the server, that's a good idea. Use custom dimension for that. Just sync it with your analysts first. Maybe they wouldn't want that, or maybe they would want it in a different dimension.
Now, this is very trivial. There are ways to go much deeper and to improve the quality of data from here. Like gluing the order id, the transaction id, the user id to that, using them to generate client id, do some custom client tracking for the future. But I must say that it's better than what more than 90% of, say, shopify clients have.
Also, GA4 is not good enough for deeper production usage. Many things there are still very rudimentary and lacking. I would suggest concentrating on Universal Analytics and having GA4 as a backup for when Google makes GA4 actually good enough to replace UA. That is, unless you're downloading your data elsewhere and not using GA's interface for analysis.
It seems that this page (Relevant portion in the screenshot below), advices to either send the data along with the client_id or user_id. However fails to address the fact client_id is a mandatory field as stated here.
I believe it is probably safe to assume that randomly generating this field should work. At least it seems to on my end however be warned that I am unsure if this has any impact on attribution.
* In the above image, Device ID refers to client_id
I have been playing around with One Signal & Firebase Push Notification.
I am almost sure One Signal cannot help me and am starting to feel Firebase might also not be able to help me.
We have a web app that allows regular authors to post articles. It also allows users to comment on the article using Firebase synced realtime database.
I want to create functionality where users can get a push notification for article-specific comment treads. The room ID will be the article ID. If both allow push notification generally from our app and has commented on an article, they subscribe to this article comment tread solely. They can also click a button at this specific article comment thread and unsubscribe to this article comment thread if they want.
So we may have thousands of articles and hundreds of comments in each article, to put it lightly.
I quickly moved away from One Signal when I didn't feel like I could have a separate "Segment" for each article, I wasn't certain this is allowed? Thoughts there?
Throughout my exploration of Firebase I just came across this comment in their documentation in relation to groups (Which I was hoping could be my article room).
"The maximum number of members allowed for a notification key is 20" found here. A key is a group key from my understanding. This won't work because what if there are more than 20 users in a comment thread. I looked up the most popular commented threads ever to find numbers like 500. This means my system would have to be able to support large numbers of users per article tread.
Additionally One Signal Tags and Social activities look like could be investigated, but my general question is not specific, its more a wider general question. I am hoping someone with experience can give some guidance and good tips on best way to approach this problem. Are Push notification even allowed on such a scale I am wondering?
A scaling examples
1000 Articles with 100s of different users commenting on each article. A user may only receive a push notification on articles which he has commented in only.
(Assuming he has allowed push notification site-wide first and not blocked us or unsubscribed from the site entirely. Subscribing to the site doesn't automatically subscribe you to anything specific, just means you willing to be subscribed to something and have control which things easily)
Ok thanks for reading and looking forward to hearing from someone with this experience and share their experience.
Daniel Gadd # GaddBox
Maybe it's a bit late.
You have to use topics.
FCM topic messaging allows you to send a message to multiple devices that have opted in to a particular topic. You compose topic messages as needed, and FCM handles routing and delivering the message reliably to the right devices.
In your case, every Article is a topic.
I want to get the timestamp of the last message in a channel using my bot. The problem is that other bots can post in the channel too and according to the FAQ the following restriction exists:
Bots talking to each other could potentially get stuck in unwelcome loops. To avoid this, we decided that bots will not be able to see messages from other bots regardless of mode.
I understand the reason, but I don't want really read these messages. I just want to know the last date of the post (because I don't want them post too often).
I’m part of a telegram group. I can see other users on the group, and I can message them individually (and manually). Is it possible to automatically (programmatically) message all the users on the group individually? Note I am not the admin.
If it is indeed possible, is there any sample code you can share?
It would be particularly awesome if the message could be customized for admin and non-admin. This means I’d need to detect if a particular user is an admin.
Thanks
I'm not sure if I get what you are looking for but I assume you have a Telegram Bot and wanna message all users in an specific group/supergroup. First I have to remind you bot can't start private message according to this link
Bots can't initiate conversations with users. A user must either add them to a group or send them a message first.
If I got it wrong feel free leave comment and I will update the answer ASAP ;-) ^_^
I am hoping to use Firebase FCM for the following scenario but do not know if it is feasible:
A reasonably large number of users (100000+) subscribe to one of a fixed number of topics (around 10000) for a very short duration (1-5 minutes) before unsubscribing and subscribing to another topic. Each user only subscribes to a single topic at any one time and for the short period that they are subscribed to each topic, I can send messages to all subscribers almost immediately after they subscribe.
Is this practical?
Are subscriptions / unsubscriptions handled in near real-time?
Is this better handled another way such as sending by registration id and handling the 'topic' myself?
First question - why do you have 10000 topics?? Even with a single device having that it wouldn't be manageable.
Is this practical? No.
Are subscriptions/unsubscriptions handled in near real time? No, that is not how subscriptions work.
Last q's ans => https://stackoverflow.com/a/44934299/8525451 [doing it via registration_ids]