Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use different write keys for an already initialized Analytics instance #360

Closed
sidbhar opened this issue Sep 13, 2024 · 1 comment
Closed
Assignees
Labels

Comments

@sidbhar
Copy link

sidbhar commented Sep 13, 2024

Is your feature request related to a problem? Please describe.
We have 2 different sources set up for sending unauthenticated vs. authenticated events. It's set up this way so we can limit damage, in case the keys are compromised. If user is signed out, events are sent to the unauthenticated source. Once the user signs in, we initialize another instance of Analytics with the appropriate write keys, and send events to the authenticated source. The unauthenticated Analytics instance is killed. This causes some issues with 2 different device_ids being created for each instance and identity merge not happening correctly (we're forwarding to Mixpanel with the simplified API).

Describe the solution you'd like
It would be great if we only had to initialize Analytics once, but could change the write key based on the user's state (signed out/in).

Describe alternatives you've considered
We could consider generating the device_id ourselves and setting it to be the same value explicitly for each instance of Analytics (and resetting it when the user signs out)

@bsneed
Copy link
Contributor

bsneed commented Sep 13, 2024

The system is not setup to work this way and I would recommend against what you're attempting to do. If you're concerned about your write key leaking somehow, it's best to download it on app launch or something instead. You'd download store it in the keychain and use it until you knew it changed.

Keeping two instances of analytics in sync w/ the same anonId, user, etc probably isn't ever going to work reliably. What you're attempting to do makes your implementation incredibly complex for something that's very unlikely to / won't ever happen.

@bsneed bsneed closed this as completed Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants