amplitude / Amplitude-TypeScript

TypeScript Amplitude Analytics SDK
https://amplitude.github.io/Amplitude-TypeScript/
MIT License
132 stars 38 forks source link

πŸ› Region/City/DMA reporting `(none)` after upgrading to React Native package v1.4.2 #627

Open go-sean-go opened 11 months ago

go-sean-go commented 11 months ago

After upgrading from "@amplitude/analytics-react-native": "^1.2.2" to "@amplitude/analytics-react-native": "^1.4.5", DMA and City info has starting returning (none) in all of my Amplitude dashboards for all new users (i.e. users whose Start Version was after the Amplitude v1.4.5 release). Existing users who had installed before v1.4.5 rolled out still persist their historical/preexisting location info - even when using v1.4.5.

Note that we do not supply any location info; we rely on the GeoIP Lookups described here: https://help.amplitude.com/hc/en-us/articles/360016257391-FAQ-User-counted-under-none-or-an-unexpected-value

(This has worked for us for almost a year, for new and existing users - and only started failing after the v1.4.5 update.)

Here is a chart showing the change - Nov 9 is when we released the Amplitude library update (from 1.2.2 to 1.4.5):

amp none curve

Expected Behavior

  1. User A installs app and runs it, triggering one or more Amplitude events.
  2. Employee views User A's events in the Amplitude dashboard
  3. By default, these events contain the Region, City, and DMA on each event, and for the user's properties in the Dashboard (see screenshot below):
amp working

Current Behavior

On number (3) above, location fields are all reporting empty/null/none. See:

amp broken

Environment

go-sean-go commented 10 months ago

Interestingly, I've found that using an older version in my package.json that includes the caret operator (e.g. "^1.2.1") still inserts the latest version/tag in to the node_modules/@amplitude/analytics-react-native/package.json file - meaning, currently, that the package.json file starts off like this:

{
  "name": "@amplitude/analytics-react-native",
  "version": "1.4.6",
  "description": "Official React Native SDK",
  ...

This causes the BugsnagReactNative.podspec file to specify the wrong source tag - :tag => "v#{s.version}" - so my Podfile.lock version is out-of-sync w/ my package.json version.

I'm not familiar with how yarn/npm packages work - at all, really - but comparing to other public repos, it looks like the Amplitude tagging naming schema (e.g. @amplitude/analytics-react-native@1.4.6) differs from other packages I've seen. Maybe that's OK, though? But I do notice that there is a leading/preceding/namespaced v at the beginning of the tag name in BugsnagReactNative.podspec that does not appear in the actual tag's name.

So: I kind of suspect this caused by some kind of tag resolution issue, and perhaps in the past it just happened to work because of timing (i.e. latest tag lined up w/ what I was already using). Or maybe there are local cache issues. I'm just reaching.

(It's almost like the Pod version is using the semver operators from my package.json vs. sync'ing the versions - the latter I suspect is the intention from the Amplitude team?)

go-sean-go commented 10 months ago

Update: can confirm the breaking package version is v1.4.2. Makes sense given the commits related to the country setter: https://github.com/amplitude/Amplitude-TypeScript/releases/tag/%40amplitude%2Fanalytics-react-native%401.4.2

https://github.com/amplitude/Amplitude-TypeScript/pull/547

qingzhuozhen commented 10 months ago

Hi @go-sean-go thanks for reporting the issue! We just released a new version and not track country value by default. This should help. Feel free to upgrade and let us know if that's still an issue.

go-sean-go commented 10 months ago

Thank you! I will test after the holiday break & report back in the early new year.

GLSinthu commented 9 months ago

Version 1.4.7 fixed this issue for me πŸ‘