App-retargeting opent het startscherm in plaats van de productpagina wanneer deep linking niet goed werkt of verkeerd is geconfigureerd. De advertentieklik geeft ofwel niet de juiste bestemmingsparameter door, of de app verwerkt de inkomende link niet correct, waardoor het besturingssysteem terugvalt op het standaard startscherm. Dit is een van de meest voorkomende oorzaken van klachten over retargeting-advertenties die de verkeerde pagina openen, en het is volledig op te lossen zodra je weet waar de fout zit. De onderstaande secties behandelen elk onderdeel van het probleem, van linktypen tot MMP-instellingen en diagnostiek.<\/p>\n
Retargeting komt op het startscherm terecht wanneer de deep link in uw advertentie niet kan worden opgelost of niet door de app wordt verwerkt. De meest voorkomende oorzaken zijn een ontbrekend of onjuist geformuleerd URI-schema, een universele link die niet door het besturingssysteem is geverifieerd, een verlopen of onjuist geconfigureerde deferred deep link, of een app-build die geen handler registreert voor het inkomende URL-pad. Wanneer geen van deze voorwaarden van toepassing is, openen iOS en Android de app gewoon op de standaard opstartlocatie.<\/p>\n
Bij retargeting is het probleem vaak subtieler dan bij organische kanalen. De gebruiker heeft de app al ge\u00efnstalleerd, dus er is geen installatieproces dat het probleem maskeert. De advertentieklik leidt direct naar de app en als de linkbestemming onjuist of afwezig is, komt de gebruiker zonder context op het startscherm terecht. Dit is een directe oorzaak van verloren winkelwagens na het opnieuw openen van de app en draagt in grote mate bij aan het afhaken bij app-onboardingcampagnes.<\/p>\n
Het probleem kan ook op het niveau van het advertentienetwerk ontstaan. Sommige netwerken verwijderen of coderen queryparameters tijdens redirect-ketens, waardoor het bestemmingspad wordt beschadigd voordat het de app bereikt. Controleer altijd hoe de uiteindelijke URL eruitziet, niet alleen wat u in de campagne-instellingen hebt ingevoerd.<\/p>\n
Een URI-schema is een aangepast protocol dat door de app is geregistreerd, zoals bijvoorbeeld: myapp:\/\/product\/123<\/strong>, dat het besturingssysteem direct naar de app doorverwijst wanneer deze is ge\u00efnstalleerd. Een universele link is een standaard HTTPS-URL, zoals https:\/\/myapp.com\/product\/123<\/strong>, dat het besturingssysteem de link onderschept en in de app opent in plaats van in de browser, op voorwaarde dat de app is geverifieerd als de eigenaar van dat domein. Het belangrijkste verschil is dat URI-schema's geen fallback hebben en door andere apps kunnen worden gekaapt, terwijl universele links netjes terugvallen op het web als de app niet is ge\u00efnstalleerd.<\/p>\n Voor retargetingcampagnes zijn universele links over het algemeen betrouwbaarder. Ze worden soepeler door de redirect-ketens van advertentienetwerken geleid, omdat het standaard HTTPS-URL's zijn, en ze vereisen geen ondersteuning van het netwerk voor aangepaste schema's. URI-schema's worden nog steeds veel gebruikt, maar ze zijn gevoeliger voor het probleem dat er na een advertentieklik een verkeerd scherm wordt weergegeven, omdat elke fout in de routering van het besturingssysteem er simpelweg voor zorgt dat er niets wordt geopend of dat het startscherm wordt weergegeven.<\/p>\n Op Android zijn app-links het equivalent van universele links. Deze gebruiken hetzelfde HTTPS-formaat en vereisen domeinverificatie via een app. assetlinks.json<\/strong> Het bestand wordt op uw server gehost. Zowel universele iOS-links als Android-applinks vereisen actief onderhoud: als het verificatiebestand wordt verwijderd of het domein verandert, werkt deep linking niet meer automatisch op alle kanalen.<\/p>\n Een uitgestelde deep link slaat de beoogde bestemming op het moment van de advertentieklik op en levert deze aan de app nadat de gebruiker deze heeft geopend, zelfs als er enige tijd is verstreken tussen de klik en de sessie. In een retargetingcontext heeft de gebruiker de app al ge\u00efnstalleerd, waardoor het uitgestelde mechanisme minder relevant is dan bij gebruikersacquisitie. Sommige retargeting-opstellingen maken echter nog steeds gebruik van uitgestelde logica, met name wanneer de MMP niet met zekerheid kan bevestigen dat de app op het moment van de klik is ge\u00efnstalleerd.<\/p>\n Het werkt heel eenvoudig. Wanneer een gebruiker op de retargeting-advertentie klikt, registreert de MMP de klik samen met de bestemmingsparameters. Bij het openen van de app roept deze de MMP SDK aan bij het starten van de sessie. Deze SDK koppelt het openen van de app aan de opgeslagen klik en retourneert het bestemmingspad. De app navigeert de gebruiker vervolgens naar het juiste scherm. Als deze handshake mislukt omdat de SDK niet vroeg genoeg is ge\u00efnitialiseerd, de sessietimeout is verlopen of de app niet reageert op de geretourneerde parameters, komt de gebruiker terecht op het startscherm.<\/p>\n Een praktische oorzaak van het verdwijnen van gebruikers na installatie of het verlies van gebruikers na installatiepatronen is dat de app deep links correct afhandelt tijdens het installatieproces, maar dezelfde logica niet implementeert voor heractiveringssessies. De SDK retourneert een bestemming, maar de app negeert deze bij koude openingen die niet de eerste installatie betreffen. Dit is een tekortkoming op codeniveau die het waard is om te controleren, met name voor retargetingverkeer.<\/p>\n De bestemming van een deep link in een retargetingcampagne wordt bepaald door een combinatie van de linkconfiguratie op campagneniveau in uw MMP, de deep link handler die is geregistreerd in de app SDK en de instellingen voor het re-engagement attributievenster. Platforms zoals Adjust, AppsFlyer en Branch hebben elk specifieke instellingen die bepalen hoe deep link-gegevens bij re-engagement naar de app worden doorgegeven. Een verkeerde configuratie op een van deze niveaus leidt tot de verkeerde bestemming.<\/p>\n In AppsFlyer wordt de waarde van de deep link ingesteld in de OneLink-sjabloon of de campagne-URL als de af_dp<\/strong> parameter voor URI-schema's of af_web_dp<\/strong> voor webfallback. In Adjust wordt de deep link doorgegeven via de deep_link<\/strong> parameter in de tracker-URL. In Branch wordt de bestemming geconfigureerd binnen de Branch-link zelf met behulp van de $deeplink_pad<\/strong> of aangepaste sleutel-waardeparen. Als deze parameters ontbreken of onjuist zijn opgemaakt, heeft de MMP geen bestemming om aan de app door te geven en wordt het startscherm weergegeven.<\/p>\n Aan de app-kant moet de SDK worden ge\u00efnitialiseerd voordat de deep link-callback wordt uitgevoerd, en de app moet de re-engagement delegate of listener apart van de install delegate implementeren. Veel apps implementeren de install deep link handler correct, maar laten het equivalent voor re-engagement weg. Bij Branch deep linking bijvoorbeeld, initSession<\/strong> De callbackfunctie behandelt zowel installatie- als heropeningsgebeurtenissen, maar de app-logica moet expliciet het sessietype controleren en in beide gevallen reageren op de geretourneerde parameters. Als deze controle wordt overgeslagen, leidt een retargeting-klik de gebruiker telkens naar het startscherm, zelfs als de link zelf correct is geconfigureerd.<\/p>\n Om een defecte deeplink in een retargetingcampagne te diagnosticeren, test je het volledige traject van klik naar scherm in de juiste volgorde: controleer of de ruwe link correct wordt opgelost, bevestig dat de app de deeplinkgegevens ontvangt en controleer of de app naar het juiste scherm navigeert. Elke stap kan afzonderlijk mislukken, dus door de laag te isoleren die de fout veroorzaakt, weet je precies waar je het probleem moet oplossen.<\/p>\n Begin met het openen van de retargetinglink direct op een apparaat waarop de app is ge\u00efnstalleerd. Gebruik een linkdebugger van je MMP, zoals AppsFlyer's OneLink Tester of Branch's TUNE linktester, om te controleren welke parameters worden doorgegeven. Controleer of de af_dp<\/strong> of een equivalente deep link-parameter aanwezig en correct geformatteerd. Een ontbrekende parameter in dit stadium wijst op een probleem met de campagneconfiguratie, niet met de code.<\/p>\n Als de parameters aanwezig zijn maar de app nog steeds het startscherm opent, voeg dan logging toe aan de SDK-callback in een testbuild om te controleren of de app de deeplink-gegevens ontvangt wanneer de app opnieuw wordt geopend. Als de gegevens wel aankomen, maar er geen navigatie plaatsvindt, ligt het probleem in de routinglogica van de app. Als de gegevens niet aankomen, ligt het probleem bij de initialisatievolgorde van de SDK of de registratie van de re-engagement listener.<\/p>\n Controleer ook het attributievenster voor hernieuwde betrokkenheid in uw MMP. Als de klik buiten dit venster valt, kan de MMP de deep link-gegevens volledig negeren en de opening als een organische sessie beschouwen. Dit is een veelvoorkomende oorzaak van het patroon 'gebruikers openen de app niet opnieuw' dat in attributierapporten verschijnt zonder duidelijke verklaring.<\/p>\n Retargetingcampagnes mogen niet zonder aanpassingen dezelfde deep links gebruiken als organische kanalen. Organische deep links zijn doorgaans ontworpen voor nieuwe gebruikers en slaan mogelijk onboardingstappen over of gaan ervan uit dat gebruikers al ingelogd zijn, wat bij terugkerende gebruikers mogelijk niet het geval is. Retargetinglinks moeten rekening houden met de sessiestatus, authenticatie en de specifieke context van de hernieuwde betrokkenheid, zoals het terugkeren naar een verlaten winkelwagen of een eerder bekeken product.<\/p>\n De bestemmings-URL of het pad kan vaak hetzelfde zijn, maar de omringende parameters moeten verschillen. Retargetinglinks profiteren van extra contextparameters die de app vertellen hoe de bezoeker moet worden verwerkt: of een inlogscherm moet worden overgeslagen, een winkelwagensessie moet worden hersteld of een specifieke promotionele overlay moet worden weergegeven. Zonder deze parameters kan de app weliswaar naar het juiste scherm navigeren, maar de context die de hernieuwde betrokkenheid waardevol maakt, ontbreekt. Dit draagt direct bij aan het verlies van winkelwagens na het opnieuw openen van de app.<\/p>\n Vanuit een trackingperspectief biedt het gebruik van aparte linkconfiguraties voor retargeting ook schonere attributiegegevens. Het combineren van organisch en betaald re-engagementverkeer via dezelfde link maakt het lastiger om te bepalen welke campagnes daadwerkelijk re-engagement genereren en welke passieve openingen. Door in uw MMP speciale retargeting-linktemplates in te stellen, blijven de rapportages nauwkeurig en kunt u problemen zoals een verkeerd scherm na een advertentieklik veel sneller diagnosticeren.<\/p>\n Problemen met deep links in retargetingcampagnes worden zelden veroorzaakt door \u00e9\u00e9n enkele fout. Ze komen meestal voort uit een combinatie van configuratiefouten in de SDK, MMP-instellingen die zijn ingesteld voor gebruikersacquisitie in plaats van hernieuwde betrokkenheid, en app-code die nooit specifiek is getest met retargetingverkeer. Het tegelijkertijd goed krijgen van al deze drie aspecten kost de meeste teams veel tijd.<\/p>\n Bij Wuzzon werken we dagelijks met Adjust, AppsFlyer en Branch en hebben we alle mogelijke varianten van dit probleem gezien in fintech-, e-commerce- en mobiele apps. app-groeistackservices<\/u><\/strong><\/a> Neem een volledige audit van je deep linking-configuratie op in de basis van je retargeting, zodat je geen geld uitgeeft aan re-engagement via een kapotte linkconfiguratie. Als je je specifieke configuratie wilt analyseren en precies wilt achterhalen waar je met retargeting gebruikers verliest, Vraag een gratis consult aan<\/u><\/strong><\/a> En dan bekijken we het samen.<\/p>\n \n Test v\u00f3\u00f3r de lancering het volledige navigatieproces van klikken naar scherm op een fysiek apparaat waarop de app al is ge\u00efnstalleerd. Gebruik de ingebouwde linkdebugger van je MMP, zoals de OneLink Tester van AppsFlyer of de linktester van Branch, om te controleren of alle bestemmingsparameters (bijv. af_dp, deep_link of $deeplink_path) aanwezig zijn en correct zijn geformatteerd in de opgeloste URL. Activeer vervolgens de link handmatig, voeg logging toe aan je SDK-callback in een testbuild en controleer of de app de deeplink-gegevens ontvangt en naar het juiste scherm navigeert, en niet alleen of het scherm wordt geopend. <\/p>\n <\/div>\n \n De meest voorkomende fout is het implementeren van de deep link handler alleen voor de installatieflow en het nooit toevoegen van de bijbehorende re-engagement listener. De MMP SDK retourneert bestemmingsgegevens bij het opnieuw openen van de pagina, net zoals bij de eerste installatie. Maar als de app alleen tijdens de installatiesessie op die gegevens reageert, zullen gebruikers bij elke retargeting-klik terugkeren naar het startscherm, ongeacht hoe goed de campagnelink zelf is geconfigureerd. Controleer uw SDK-integratie specifiek op re-engagement callbacks \u2014 in Branch betekent dit bijvoorbeeld dat u moet controleren of uw initSession-logica de heropeningsgebeurtenissen expliciet afhandelt. <\/p>\n <\/div>\n \n Dit wijst er bijna altijd op dat parameters ergens in de redirect-keten van het advertentienetwerk worden verwijderd of gecodeerd. De link die u in uw campagne-instellingen configureert, is zelden de uiteindelijke URL die het apparaat ontvangt. Advertentienetwerken voegen vaak hun eigen redirect-lagen toe die aangepaste queryparameters kunnen beschadigen of verwijderen. Haal de daadwerkelijke, uiteindelijk opgeloste URL op uit de ruwe data of postback-logs van uw MMP en vergelijk deze teken voor teken met uw oorspronkelijke configuratie. Als parameters ontbreken of onjuist zijn geformuleerd in de live URL, neem dan contact op met uw advertentienetwerk om de specifieke parameters die uw MMP vereist, op een whitelist te plaatsen of te behouden. <\/p>\n <\/div>\n \n Als een gebruiker op een retargeting-advertentie klikt, maar de app opent buiten het geconfigureerde re-engagement-attributievenster van uw MMP, zal de MMP die opening doorgaans als een organische sessie beschouwen en helemaal geen deep link-bestemmingsgegevens naar de app doorgeven. Het resultaat is een landingspagina op het startscherm die eruitziet als een technische deep link-fout, maar in werkelijkheid een probleem met de attributieconfiguratie is. Controleer uw re-engagement-vensterinstellingen in Adjust, AppsFlyer of Branch en zorg ervoor dat ze lang genoeg zijn ingesteld om realistische vertragingen tussen advertentieklik en app-opening te dekken, met name voor push-gebaseerde of e-mail-getriggerde retargeting. <\/p>\n <\/div>\n \n Ja, en de verschillen gaan verder dan alleen het URI-schema versus App Links. Op iOS vereisen Universal Links een actief apple-app-site-association (AASA)-bestand dat op uw domein wordt gehost, en Apple's CDN cachet dit bestand agressief. Dit betekent dat wijzigingen enige tijd nodig hebben om door te voeren en dat een verkeerd geconfigureerd bestand stilletjes deep linking in alle campagnes kan verstoren. Op Android vereisen App Links een geldig assetlinks.json-bestand en een correcte registratie van intentfilters in het app-manifest. Beide platforms moeten onafhankelijk van elkaar worden geconfigureerd en getest, en beide kunnen zonder zichtbare foutmeldingen uitvallen als domeinverificatiebestanden worden verwijderd of het domein wordt gewijzigd. <\/p>\n <\/div>\n \n Ja, dit is een veelvoorkomende, maar vaak over het hoofd geziene fout bij retargeting. Als de app authenticatie vereist voordat een productpagina of winkelwagenscherm wordt weergegeven, zal een deeplink die direct naar die bestemming navigeert, vastlopen op een inlogscherm en ofwel doorverwijzen naar het startscherm, ofwel een foutmelding weergeven. Retargetinglinks moeten sessie-state parameters bevatten die de app instrueren om de beoogde bestemming op te slaan, het inlogproces te voltooien en de gebruiker na authenticatie door te verwijzen naar het juiste scherm. Zonder deze logica leidt zelfs een perfect geconfigureerde deeplink tot een mislukte retargeting-ervaring. <\/p>\n <\/div>\n \n Controleer uw deeplink-configuratie telkens wanneer u een nieuwe app-versie uitbrengt, uw domein of URL-structuur wijzigt, uw MMP SDK bijwerkt of een nieuw advertentienetwerk toevoegt. Het niet meer werken van deeplinks wordt zelden veroorzaakt door \u00e9\u00e9n enkele wijziging; het is meestal het gevolg van geleidelijke veranderingen in de app-build, MMP-instellingen en advertentienetwerkconfiguratie in de loop van de tijd. Een praktisch minimum is een gestructureerde controle eens per kwartaal, plus een onmiddellijke controle wanneer u een piek in het aantal landingspagina's of een daling in de kwaliteit van hernieuwde sessies in uw attributierapporten ziet. <\/p>\n <\/div>\n <\/div>","protected":false},"excerpt":{"rendered":" Broken deep links send retargeting users to the home screen \u2014 here’s exactly why it happens and how to fix it.<\/p>","protected":false},"author":16,"featured_media":12316,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[56],"tags":[],"class_list":["post-12130","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/posts\/12130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/comments?post=12130"}],"version-history":[{"count":1,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/posts\/12130\/revisions"}],"predecessor-version":[{"id":12260,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/posts\/12130\/revisions\/12260"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/media\/12316"}],"wp:attachment":[{"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/media?parent=12130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/categories?post=12130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/tags?post=12130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Hoe werkt een uitgestelde deep link bij retargeting?<\/h2>\n
Welke MMP- of SDK-instellingen bepalen de bestemming van de deep link?<\/h2>\n
MMP-campagneconfiguratie<\/h3>\n
Afhandeling van heractivering van de SDK<\/h3>\n
Hoe diagnosticeer je een defecte deep link in een retargetingcampagne?<\/h2>\n
Moeten retargetingcampagnes dezelfde deeplinks gebruiken als organische kanalen?<\/h2>\n
Hoe wij u kunnen helpen bij het oplossen van deep linking-problemen en het opschalen van retargeting.<\/h2>\n
Veelgestelde vragen<\/h2>\n
\n Hoe test ik of mijn deeplink voor retargeting werkt voordat ik een campagne lanceer? <\/h3>\n
\n Wat is de meest voorkomende fout die teams maken bij het opzetten van deep links voor hernieuwde betrokkenheid? <\/h3>\n
\n Wat moet ik doen als mijn deeplink wel werkt tijdens het testen, maar niet in live campagnes? <\/h3>\n
\n Hoe be\u00efnvloedt het hernieuwde betrokkenheidstoewijzingsvenster de levering van deeplinks? <\/h3>\n
\n Vereisen iOS en Android verschillende deep link-configuraties voor retargetingcampagnes? <\/h3>\n
\n Kan een correct geconfigureerde deep link nog steeds niet werken als de gebruiker is uitgelogd uit de app? <\/h3>\n
\n Hoe vaak moet ik mijn deep link-configuratie voor retargetingcampagnes controleren? <\/h3>\n