Liens profonds différés dans iOS
Nous essayons de mettre en œuvre un lien profond différé dans l'une de nos applications iOS pour encourager les utilisateurs à inviter leurs amis à utiliser l'application et récompenser les utilisateurs en fonction du nombre d'installations effectuées à partir de leur lien de parrainage. Fondamentalement similaire à produit de TapStream .
Considérez cet exemple:
Ainsi, UserA partage son lien, "ourappURL.com/refer?id=userA", sur le réseau de son choix. UserB clique sur ce lien, ce qui les mènera à Safari, puis les renverra sur la page App Store où UserB télécharge l'application.
Lorsque UserB ouvre l'application, l'application vérifie l'ID de référence sur lequel ils sont arrivés (le cas échéant). Dans cet exemple, l'ID de référence serait "userA" car c'est l'ID qui était dans le lien de référence. L'application envoie ensuite cela à nos serveurs et nous accordons à UserA un crédit de parrainage.
J'essaie de décomposer ce problème en ses parties principales. Je crois que la première partie consiste à obtenir la page Web du lien de référence de l'utilisateur pour enregistrer l'ID de référence sur l'appareil quelque part où l'application peut y accéder. Mais je ne suis pas sûr que cela soit possible en raison de la nature en bac à sable d'iOS.
Je sais que cela est fondamentalement possible car de nombreux fournisseurs d'annonces offrent la possibilité de suivre les installations à partir d'une campagne publicitaire (voir le suivi des applications mobiles par exemple).
Nous avons également tenté de le faire nous-mêmes et je vais essayer de décomposer les différentes étapes ici.
Pour revenir à votre exemple, vous avez raison de "mémoriser" l'identification de l'appareil et toutes les données pertinentes "id = userA". Vous avez également raison sur la "nature en bac à sable d'iOS", ce qui, je suppose, signifie qu'une page Web n'est pas autorisée à stocker des informations en dehors de l'application de navigateur (Safari) et que les applications (votre application) ne peuvent pas accéder aux informations stockées par d'autres applications ( Safari).
Notre solution consiste à stocker cet appareil dans une paire clé-valeur de données dans un environnement accessible à la fois par le navigateur et par votre application, c'est-à-dire votre serveur principal.
Le prochain défi, qui reste le plus grand défi, est de savoir comment identifier cet appareil de manière unique à partir des informations collectables à partir du navigateur? Les javascripts dans les navigateurs, contrairement aux applications natives, n'ont pas accès aux IDFA qui pourraient être utilisés pour identifier de manière unique un appareil iOS. Pour surmonter cela, on peut imaginer utiliser une combinaison d'informations communes disponibles à la fois pour l'application navigateur et pour votre application native, c'est-à-dire le type de système d'exploitation, l'adresse IP publique, la taille de l'écran, etc. etc. Veuillez noter qu'une clé composite de ces champs de données ne garantissent pas l'unicité (imaginez deux iPhone 6 visitant cette page Web via le même routeur). Par conséquent, votre serveur principal (en supposant que vous l'utilisez pour stocker cette paire clé-valeur), voudra avoir une stratégie sur la façon de gérer les collisions sur les clés, c'est-à-dire que la deuxième clé supprime la première clé, ou vous permettez à la collision d'exister en ayant une file d'attente de valeurs pour une seule clé. Cela dépend vraiment de la façon dont vous prévoyez d'utiliser cette technologie.
La dernière étape consiste à former cette clé composite sur votre application en utilisant les mêmes champs que vous avez utilisés précédemment dans le navigateur pour effectuer une "recherche" sur votre serveur principal pour récupérer la valeur précédemment stockée.
Voici un résumé des étapes:
- L'utilisateur 1 invite l'utilisateur 2 en envoyant le lien suivant à 2: example.com?inviter=1
- L'utilisateur 2 visite la page Web P
- P construit et envoie la paire clé-valeur suivante à votre serveur S iOS | 55.55.55.55 | 750 × 1334 -> inviter_id = 1
- L'utilisateur 2 se rend sur l'App Store et télécharge votre application A
- Lors de 2 premiers lancements de A, A contacte S avec la même clé (en supposant que l'IP n'a pas changé).
- S trouve la valeur inviter_id = 1 en utilisant cette clé transmise et, disons, récompense l'utilisateur 1 de cinq points pour avoir invité 2.
J'espère que cette aide!
Modifier le 24/04:
Puisque Derrick l'a mentionné dans les commentaires, je pense que je saisirais cette occasion pour terminer notre histoire ici.
Pour en revenir au début de ma réponse où j'ai mentionné que nous avons tenté de le faire nous-mêmes. Nous avions un prototype fonctionnel basé sur notre architecture système actuelle (qui n'est en aucun cas optimisée ou destinée à être optimisée pour le stockage et l'analyse de données de liens profonds comme celui-ci), nous avons finalement décidé de ne pas allouer de ressources d'ingénierie supplémentaires à ce projet.
En raison de la nature heuristique de ce processus d'appariement, nous avons trouvé que ce projet nécessitait un débogage, un réglage et une optimisation constants pour un retour sur investissement décroissant. Plus important encore, nous avons trouvé d'autres entreprises plus spécialisées et qui font un bien meilleur travail que nous.
Cela fait probablement 6 mois que nous n'avons plus utilisé notre système interne et nous n'avons pas regretté d'avoir pris une telle décision.
Au cours de ces processus, nous avons travaillé avec un certain nombre de fournisseurs, Appsflyer, Adjust, TapStream et nous nous sommes finalement retrouvés avec Branch Metrics https://branch.io .
Que vous deviez bricoler ou travailler à nouveau avec une autre entreprise dépend de votre objectif spécifique. Nous avons finalement décidé de rester avec Branch, non seulement parce que les autres fournisseurs facturaient entre 500 $ et des milliers de dollars par mois alors que Branch était totalement gratuit, mais aussi le niveau de support qu'ils ont fourni est tout simplement sans précédent.
Il y a une bonne solution ici: http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/
Flux de travail de base:
- L'utilisateur sélectionne le lien de domaine sur le Web.
- Le lien définit l'ID de référence sur le cookie.
- L'utilisateur a été redirigé vers l'App Store.
- Au lancement de l'application, chargez la page de référence dans SFSafariViewController.
- La page de référence vérifie s'il y a un cookie et s'il existe, appelle un lien profond dans l'application avec l'ID de référence.
Nous avons utilisé avec succès le presse-papiers (NSPasteboard) pour y parvenir: la page Web qui traite la redirection vers l'App Store fait un collage dans le presse-papiers de l'appareil mobile avant de laisser l'utilisateur télécharger l'application. Une fois l'application installée, elle utilise NSPasteboard au premier lancement pour rechercher une chaîne correctement codée. Cette chaîne peut contenir le texte d'intérêt ou, de manière plus sécurisée, un jeton utilisé pour récupérer des données intéressantes du backend. Dans l'objectif C:
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;
Le presse-papiers peut être effacé une fois l'application terminée, pour éviter de répéter la même action.