Feat/sdk setup for migrations

[matrixxonek]

To easily follow the changes and review them, I recommend going commit by commit instead of file by file.

This version is still open to suggestions and possible changes, so if something needs adjusting / you have objections, feel free to let me know.

In examples/expo-bare I'm leaving an app for testing the added functionality, and below is a short overview of what was added there:

#	Feature	How to trigger	What to check in the payload/behavior
1	device_id	Cold start	device_id present, the same after an app restart (persisted)
2	customer_user_id	"Set test customer_user_id" button, then "Log test event"	customer_user_id: "test-user-123" in the next event
3	IDFV (iOS) / AAID (Android) / IDFA (iOS with ATT)	Cold start, then "Log test event"	idfv on iOS always; aaid on Android (real device, not an emulator — emulators sometimes return zeros); idfa on iOS only after ATT consent
4	ATT prompt + auto-consent (iOS)	First launch on iOS with shouldRequestTrackingPermission: true in the config (add it temporarily to App.tsx to test)	The system prompt appears; after answering, att_status in the event is granted/denied, and with no extra action consent.ad/consent.tracking are set too (source: "att")
5	setTrackingAuthorizationStatus (override)	"Override ATT status: granted/denied" buttons	att_status in the next event changes immediately; consent updates as well (same mechanism as #4, just forced manually)
6	setAdvertisingId (override)	"Override advertising id (manual)" button	aaid/idfa (depending on the platform) = 11111111-2222-3333-4444-555555555555 in the next event, the native API is no longer queried
7	Android AAID opt-out → auto-consent	On a real Android device: Settings → Google → Ads → Opt out of Ads Personalisation, then restart the app	aaid = undefined in the event (sentinel filtered out), consent.ad: false, source: "aaid-optout" without calling anything manually
8	setConsent	"Set consent: all granted/denied" buttons	consent: { ad, analytics, tracking, source: "manual", updatedAt: <timestamp> } in the next event
9	logConversion	"Log test conversion (revenue)" button	Event with event_name: "purchase", revenue: 9.99, currency: "USD", product_id: "test_sku_1", quantity: 1, transaction_id: "test-txn-001"
10	app_version/build_number	Any event	Values matching app.json/the native build (change version/buildNumber in app.json, rebuild, verify they change)
11	os_version/locale	Any event	os_version matching the system, locale = an array with languageTag; change the system language and verify it changes after a restart
12	session_id + rotation after 30 min	Fire an event → note the session_id → return to the same event without backgrounding → same session_id. Then: background the app (home button), wait — temporarily lower SESSION_TIMEOUT_MS in packages/react-native-detour/src/analytics/hooks/useSessionTracking.tsx to e.g. 10s just for this test, rebuild, background for >10s, come back, fire an event	After returning from a short background: same session_id. After returning from a background longer than the timeout: a new session_id. Remember to revert the timeout change after the test
13	UTM from Install Referrer (Android)	Requires a real install from the Play Store (internal testing track) with a link containing utm_source/utm_medium/utm_campaign — dev builds usually have no referrer (see the example's README)	The payload sent to match-link contains utm: {...}
14	Deferred link + fingerprint (existing, just make sure nothing broke)	Uninstall the app, open a Detour link in the browser, install, launch	isLinkProcessed: true, type/url/route get populated

[SikoraKam]

Good work but it requires some refactor and clarifications.

Besides comments to specific places I have two general requests.

1. Add documentation to pr which will describe each new field, each new setter and how to use it and what are the benefits. Move some comments documenting whole process from code to that documentation
2. These code starts to becoming messy and and only understandable to ai. We need to keep separate logic for analytics, matching and now data collection as strictly as possible. Avoid mixing modules and long data flow between a few functions/hooks.
   Please look for some refactor options besides these mentioned in comments

[SikoraKam]

how we will treat deviceId now? is it still needed?

[matrixxonek]

Yes, it is still at fiew points:

1. deviceId will be added to every event, also to purchase event. Thanks to this we are able to connect install from specific campain with other events. That enables us to count ROAS for specific campain. It is part of MMP requirements.

But you can ask if any other ids that we collect wouldn't be better for that. After some analysis i came to the conclusion that none of other ids like IDFV or AAID is as safe to match events with install as deviceId is because deviceId is set always regardless of consents.

2. There is always possibility that other id's will never be set because of some consents or lack of informations from app host. But deviceId can still be used to safely match all of events to one specific user

[SikoraKam]

I don't know what is device_uuid - the only place where this name exists are these comments

[matrixxonek]

Device_uuid is concept that should be implemented in future backend changes. Backend will collect AAID for android or IDFV for IOS, then normalize and hash this id. It will happen for both data collected from our sdk and data send by migration process. Thanks to this we will be able to match same device from previous deeplink software as apps flyer with our id. Both ids themselves can be equal, but different software can pass in different formatting for example camelcase etc. For now it's just a concept that still need to be specified, so i will get rid of this from comments so it will not be misleading.