Uitgestelde Deep Linking in iOS

We proberen uitgestelde deep linking te implementeren in een van onze iOS-applicaties om gebruikers aan te moedigen hun vrienden uit te nodigen om de app te gebruiken, en om gebruikers te belonen op basis van het aantal installaties dat plaatsvindt via hun verwijzingslink. In principe vergelijkbaar met het product van TapStream.

Beschouw dit voorbeeld:

Dus, UserA deelt hun link, “ourappURL.com/refer?id=userA”, op elke
netwerk dat ze willen. UserB klikt op die link, waardoor ze naar:
Safari en bounce ze vervolgens naar de App Store-pagina waar UserB
downloadt de app.

Wanneer UserB de app opent, controleert de app welke verwijzings-ID ze binnenkwamen
op (indien aanwezig). In dit voorbeeld zou de verwijzings-ID “userA” zijn als
dat is de ID die in de verwijzingslink stond. De app stuurt dit vervolgens naar
onze servers en we belonen UserA met een verwijzingskrediet.

Ik probeer dit probleem op te splitsen in de kern. Ik geloof dat het eerste deel is om de webpagina voor de verwijzingslink van de gebruiker te krijgen om de verwijzings-ID op het apparaat op te slaan ergens waar de app er toegang toe heeft. Maar ik weet niet zeker of dit mogelijk is vanwege het sandbox-karakter van iOS.

Ik weet dat dit in principe mogelijk is omdat veel advertentieproviders de mogelijkheid bieden om installaties van een advertentiecampagne te volgen (zie bijvoorbeeld Tracking van mobiele apps).

Antwoord 1, autoriteit 100%

We hebben dit zelf ook geprobeerd en ik zal proberen de verschillende stappen hier uiteen te zetten.

Om terug te keren naar uw voorbeeld, u heeft gelijk over het “onthouden” van de apparaatidentificatie en alle relevante gegevens “id=userA”. Je hebt ook gelijk over het “sandbox-karakter van iOS”, wat volgens mij betekent dat een webpagina geen informatie mag opslaan buiten de browser-app (Safari) en dat apps (je app) geen toegang hebben tot informatie die is opgeslagen door andere apps ( Safari).

Onze oplossing hiervoor is om dit apparaat op te slaan als gegevenssleutel/waarde-paar in een omgeving die zowel toegankelijk is voor de browser als voor uw app, d.w.z. uw backend-server.

De volgende uitdaging, die de grootste uitdaging blijft, is hoe dit apparaat uniek te identificeren aan de hand van de informatie die via de browser kan worden verzameld? Javascripts in browsers hebben, in tegenstelling tot native apps, geen toegang tot IDFA’s die kunnen worden gebruikt om een ​​iOS-apparaat uniek te identificeren. Om dit te verhelpen, kan men zich voorstellen een combinatie te gebruiken van algemene informatie die zowel beschikbaar is voor de browser-app als voor uw eigen app, dwz type besturingssysteem, openbare IP, schermgrootte, enz. enz. Let op, een samengestelde sleutel van deze gegevensvelden garanderen geen uniciteit (stel je voor dat twee iPhone 6 deze webpagina bezoeken via dezelfde router). Daarom zal uw backend-server (ervan uitgaande dat u deze gebruikt om dit sleutel-waardepaar op te slaan), een strategie willen hebben over hoe om te gaan met botsingen op sleutels, dat wil zeggen dat de tweede sleutel de eerste sleutel verwijdert, of u laat een botsing bestaan ​​door te hebben een wachtrij van waarden voor een enkele sleutel. Dit hangt echt af van hoe u deze technologie daadwerkelijk wilt gebruiken.

De laatste stap is om deze samengestelde sleutel in uw app te vormen met exact dezelfde velden die u eerder in de browser gebruikte om een ​​”lookup” uit te voeren op uw backend-server om de eerder opgeslagen waarde op te halen.

Hier is een samenvatting van de stappen:

1. Gebruiker 1 nodigt gebruiker 2 uit door de volgende link te sturen naar 2: example.com?inviter=1
2. Gebruiker 2 bezoekt webpagina P
3. P construeert en verzendt het volgende sleutel-waardepaar naar uw server S iOS|55.55.55.55|750×1334 -> inviter_id=1
4. Gebruiker 2 gaat naar de app store en downloadt je app A
5. Gebruiker 2 start eerst A, A neemt contact op met S met dezelfde sleutel (ervan uitgaande dat het IP-adres niet is gewijzigd).
6. S vindt de waarde inviter_id=1 door deze ingevoerde sleutel te gebruiken en, laten we zeggen, gebruiker 1 vijf punten belonen voor het uitnodigen van 2.

Ik hoop dat dit helpt!

Bewerk 24/04:

Sinds Derrick het in de opmerkingen noemde, denk ik dat ik deze kans zou aangrijpen om ons verhaal hier af te maken.

Teruggaand naar het begin van mijn antwoord, waar ik zei dat we probeerdendit zelf te doen. We hadden een werkend prototype op basis van onze huidige systeemarchitectuur (die op geen enkele manier is geoptimaliseerd, of bedoeld is om te worden geoptimaliseerd, voor het opslaan en analyseren van deep link-gegevens zoals deze), we hebben uiteindelijk besloten geen extra technische middelen toe te wijzen aan dit project.

Vanwege de heuristische aard van dit afstemmingsproces, vonden we dat dit project voortdurend moest worden opgespoord, afgesteld en geoptimaliseerd voor een afnemende ROI. Wat nog belangrijker is, we hebben andere bedrijven gevonden die meer gespecialiseerd zijn en veel beter werk leveren dan wijzelf.

Het is waarschijnlijk zes maanden geleden dat we zijn gestopt met het gebruik van ons interne systeem en we hebben er geen spijt van gehad dat we deze beslissing hebben genomen.

Tijdens dit proces hebben we samengewerkt met een aantal leveranciers, Appsflyer, Adjust, TapStream en zijn we uiteindelijk uitgekomen bij Branch Metrics https://branch.io.

Of je weer aan de slag moet of met een ander bedrijf gaat werken, hangt af van je specifieke doel. We hebben uiteindelijk besloten om bij Branch te blijven, niet alleen omdat de andere leveranciers tussen de $500 en duizenden dollars per maand rekenden terwijl Branch volledig gratis is, maar ook omdat het niveau van de ondersteuning die ze hebben geboden gewoon ongeëvenaard is.

Antwoord 2, autoriteit 14%

We hebben met succes het klembord (NSPasteboard) gebruikt om dit te bereiken: de webpagina die de omleiding naar de app store verwerkt, plakt een plak op het klembord van het mobiele apparaat voordat de gebruiker de app kan downloaden. Nadat de app is geïnstalleerd, gebruikt deze NSPasteboard bij de eerste keer opstarten om te controleren op een correct gecodeerde tekenreeks. Deze tekenreeks kan de gewenste tekst bevatten of, veiliger, een token dat wordt gebruikt om interessante gegevens van de backend op te halen. In doelstelling C:

UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;

Het klembord kan worden gewist zodra de app ermee klaar is, om te voorkomen dat dezelfde actie wordt herhaald.

Antwoord 3, autoriteit 11%

Hier is een goede oplossing: http: //blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/

Basiswerkstroom:

• Gebruiker selecteert domeinlink op internet.
• Link stelt verwijzings-ID in op cookie.
• Gebruiker doorgestuurd naar app store.
• Laad bij het starten van de app de verwijzingspagina in SFSafariViewController.
• Verwijzingspagina controleert op cookies en roept, indien aanwezig, een deeplink aan naar de app met de verwijzings-ID.

Antwoord 4

Mijn antwoord van HIER

Apple ondersteunt geen deeplinks meer. Het heet nu Universal Links en werkt een beetje anders.

Bron

Nu Apple URI-schema’s voor deeplinking niet langer ondersteunt, moeten ontwikkelaars Universal Links implementeren om correct te deeplinken op iOS. Als je al URI-schema’s gebruikt, bekijk dan onze blog over de overstap naar Universal Links.

Van: HIER

En HIERis een ander artikel over Universal Links en wat ze zijn.