Whatever I try, I get my user associated to the Telegram data center 4.
In this way I immediately receive the messages sent by users/channels on the same data center (Europe?), but I get messages sent by some other channels with 4-5 seconds of delay and I believe those messages are sent by users on the data center 1 (USA/America).
This is the documentation about data centers:
https://core.telegram.org/api/datacenter
The client does not yet know which DC it will be associated with; therefore, it establishes an encrypted connection to a random address and sends its query to that address.
Having received a phone_number from a client, we can find out whether or not it is registered in the system. If it is, then, if necessary, instead of sending a text message, we request that it establish a connection with a different DC first (PHONE_MIGRATE_X error).
If we do not yet have a user with this number, we examine its IP-address. We can use it to identify the closest DC. Again, if necessary, we redirect the user to a different DC (NETWORK_MIGRATE_X error).
Now, besides some normal attempts, I have registered a new user via a US proxy, the nearestDC request returned 1 as nearest data center and US as country, but still the response to the auth.sendCode request was a migration to the data center 4. The same happens if I try to send any request to any other DC (except for files stored there).
How can I get a user registered or migrated to the data center 1?
And, is it the different data center the reason for the delay on SOME CHANNELS messages?
I know that, by the docs, my user could be migrated to a different data center if I keep connecting from an IP address near to it, but given that it did not work with registration, I'm not eager to waste may be one month or more for this kind of attempt; I would rather get a fresh user directly on the data center 1.
Use text now app to get a number outside from your country
like for DC1 choose Washington
After that create a new account using that number in telegram.
After using that account for a while, you can delete your personal account.
Go to the settings of the new account and change the phone number to your own personal number.
IE, data center won't change if u change phone number
Related
this might sound like a weird question, but is it possible to change the id of a device?
The unique id that i was using will desapear in my system source so i would like to change it.
I noticed that if a change the ids that are returned by the sync request the users will loose their customization in google home (the name of the device if they changed it and the associated room)
I would like to change it without loosing that.
The device ID is the string that identifies the device. There is no way to change.
The ID of the device in the developer's cloud. This must be unique for the user and for the developer, as in cases of sharing we may use this to dedupe multiple views of the same device. It should be immutable for the device; if it changes, the Assistant will treat it as a new device.
If it is going to change in some source, you should find a way to continue the value through some sort of proxy.
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 am new to implement Android notification channel in Oreo. What is the maximum number of notification channels for a single application. Can we create unlimited channels or it has some count?
As far as I know there is no limit on the number of channels an app can create. The only purpose of NotificationChannel is to give more control of notification behavior to the user. It is no way to reduce the number of notification per app.
You can read about Notification Channel in detail at Create and Display Notification on Android Oreo | With Example
There is a limit that is not documented on the number of channels you can have at the same time, but no limit on how many times you can create a channel, as long as you have deleted other channels.
The file PreferencesHelper.java contains a limit that is currently set to 50.000
https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/services/core/java/com/android/server/notification/PreferencesHelper.java
And this is being used to restrict the creation of more channels when it goes over that limit, throwing the exception "Limit exceed; cannot create more channels"
Unfortunately that value is not publicly accessible, so any limit check you might want to implement will have to be hardcoded by yourself. My suggestion is to set your own limit to a number that you think starts being unreasonable, and when that is reached you run a check on your notification channels to figure out what is going on, and fix it. For example, if your app will never need more than 5 channels to be created, then setting the limit to 6 would be a good way to start.
The commit https://github.com/aosp-mirror/platform_frameworks_base/commit/f528b337dd48b7e8071269e07e610bd4a3668c75 update the max notification channel to 5.000
Coming with Android Oreo, Notification Channels are something a developer uses to break down the notifications his or her app can give to us by type. The channels are decided by the people doing the developing, and the idea is to give us a way to separate out the notifications that are important to us from the ones that aren't, then decide how they will be shown. Some apps will have a lot of different channels. Some will have just a few and some will have only one.
In versions of Android before O, a developer used what was called a priority level to decide how to show you a notification. If they felt the notification was important, they could set it to peek (show a visual indication on your screen) or make a sound, or both. If they felt it wasn't it would just be placed in the tray for you to see the next time you went through them.
Now they break things out into channels and we get to decide how each type of notification is displayed. All notifications of the same type (for example, a reply on your Twitter feed) are placed into the same channel without any other types of notification grouped with them.
As a bonus, apps that allow us to use more than one account can have channels for each combined — your personal email and work email can follow the same rules and show you things the same way no matter which accounts received the notification.
You should read this:
https://developer.android.com/guide/topics/ui/notifiers/notifications.html#ManageChannels
Example:
Background of my specific environment: I am trying to set up GA to track the user journeys around an iOS native app written in React Native. The app is in-house only and all users consent to being tracked in this way.
As I understand it, the measurement protocol allows either Client ID (cid) or User ID (uid). In the docs, both are optional, but at least one is required. Makes sense so far. Client ID is an anonymous UUIDv4 that tracks a browser or device, but not necessarily a user. User ID on the other hand is some uniquely-identifying value for a user, but may cross devices/browsers.
Initially I wrote my application using cid (as I hadn't yet read the docs on uid). Every time a user logged in the user's uuid would be stored and sent as the cid parameter. I also used session control sc. This worked - I saw sessions coming in, the User Explorer showed me the individual user uuids and sessions, etc. But upon rereading the docs, this seemed like an incorrect use of cid. It seems like cid is meant to be consistent and not something that changes as you log in and out.
As people on my app can log in and out (and possibly will - staff members may well share devices), using a long-lasting cid that is specific to the device won't allow me to track the habits of individual users and changing it per login-session, as mentioned above, feels wrong.
So I switched out cid for uid. The docs say both are optional and one is only required if the other is not used, so I figured I could just use uid and use the user's uuid in that field and it's otherwise act the same.
However, when doing it this way no hits seems to be registered at all - in "real time data" as well as the User Explorer.
Am I doing something wrong or is this by design? (If by design, are the docs wrong to say cid and uid are both optional or am I reading it incorrectly?)
Either way, best-practices-wise, do I:
Just go back to using an ephemeral cid that only changes when people log in and out. Individual sessions in the app don't change the cid but I do use sc to explicitly start and end sessions by navigation inference (click 'home' = sc=end, navigate from 'home', sc=start).
Use uid as I am trying to (i.e. switching out the current cid for uid), but also include a random cid that never changes (regardless of session lifetime, logging in and out, etc.).
Something else?
I have seen this question and its answer but it does not really answer my actual question regarding how cid and uid should actually be used, and if my issue is me or the way that GA works.
Oki so client-id is randomly generated value and must be sent with all hits.
In a non-User-ID-enabled view, Client-ID is used to calculate unique users. In a User-ID-enabled view, User-ID is used to calculate unique users
In reference to your app, you can send the unique Device id value in place of random value for client-id. This will resolve all your problems and ensure that the client id is sent with all the hits, otherwise it wont get registered in GA
Ok! So I have spoken to a google representative about this issue, however since I am not enterprise level, he can't push me to tech support and suggested that I use the SO for answers. Here is the question...
In Google Maps Terms it states the following:
(b) No Pre-Fetching, Caching, or Storage of Content. You must not pre-fetch, cache, or store
any Content, except that you may store: (i) limited amounts of Content for the purpose of
improving the performance of your Maps API Implementation if you do so temporarily (and in
no event for more than 30 calendar days), securely, and in a manner that does not permit
use of the Content outside of the Service; and (ii) any content identifier or key that
the Maps APIs Documentation specifically permits you to store. For example, you must not
use the Content to create an independent database of "places" or other local listings
information.
This led me to originally believe that google would not allow caching of any type of information. However, then I read the following:
When to Use Client-Side Geocoding
The basic answer is "almost always." As geocoding limits are per user session, there is no risk that your application will reach a global limit as your userbase grows. Client-side geocoding will not face a quota limit unless you perform a batch of geocoding requests within a user session. Therefore, running client-side geocoding, you generally don't have to worry about your quota.
Two basic architectures for client-side geocoding exist.
Run the geocoding and display entirely in the browser. For instance, the user enters an address on your page. Your application geocodes it. Then your page uses the geocode to create a marker on the map. Or your app does some simple analysis using the geocode. No data is sent to your server. This reduces load on your server, but doesn't give you any sense of what your users are doing.
Run the geocode in the browser and then send it to the server. For instance, the user enters an address. Your application geocodes it in the browser. The app then sends the data to your server. The server responds with some data, such as nearby points of interest. This allows you to customize a response based on your own data, and also to cache the geocode if you want. This cache allows you to optimize even more. You can even query the server with the address, see if you have a recently cached geocode for it, and if you do, use that. If you don't, then return no result to the browser, and let it geocode the result and send it back to the server to for caching.
So one side says you cannot cache, the other side tells you, you should. Another solution it states is to always use clientside when you can, but then this becomes a grey area as well, because both examples state that you must have a user input data. What if the jquery read data from a div or span and then geocoded the information? The user wouldn't have actually done the geocode,but it was still done client-side? I'm trying to create a site that has a bunch of events generated by users and this site could get pretty loaded, so I am trying to determine the best practice in being able to do this. Google suggested here, so before you go and say this is "off-topic" please note, this is where they stated me to post.
Any feedback would be greatly appreciated.
The first quote does not explicitly forbid caching data at all. It is ambiguous as to how much you can cache (what number explicitly is "limited amounts"?) but it does not forbid caching.
You are allowed to cache the data if it helps improve the performance of your site as long as you retain the data for no longer than 30 days and do not make it available in any way to any other service except the service that originally retrieved the data.
Regarding user interaction - if your user explicitly enters a page with the expectation that they will be shown geocoded information I would assume that this would fulfill "user interaction".
As an example from a project I worked on last year I had it set up to do the following:
- Show markers on the map
- If the user clicked a marker they were shown a popup with data from the cache if available, otherwise a geocode would be performed and the returned information would be cached along with the date/time of the cache.
Another page of the site showed a history of these markers at 5 minute intervals throughout the day. If cached data was present (from clicking the map marker as in the previous part) this would be shown, otherwise a geocode would be performed and the data cached as before. The user clicking to run the report was (in my opinion) enough "user interaction" to not count as pre-fetching as the user had to manually select a timeframe before the report would be displayed.
A cronjob then ran every day at midnight which would go through each record with cached data over 25 days old and remove it.
As it was I was caching much less than 10% of the marker positions being shown (20+ markers being updated every minute, but the report was being run on maybe 3-5 markers each day and only geocoding data for every 5th point).