Wat is Signal Engineering, en wat lost het op na ATT?

U bent hier waarschijnlijk omdat

Geen van deze zijn media buying-problemen. Het zijn signaalproblemen, en de meeste zijn op te lossen.

• Meta rapporteert de ene ROAS, RevenueCat rapporteert de helft daarvan, en finance gelooft geen van beide. Ze zullen nooit overeenkomen, en niemand in het team kan zeggen waarom.
• Uw SKAN-conversiewaarden komen bij de meeste campagnes leeg terug en niemand weet waarom.
• Meta schaalt prima. Google en TikTok lopen vast op dezelfde creative.
• U bent overgestapt op value optimization en het werd erger.
• Trial starts zijn goedkoop en betaalde conversies volgen nooit.
• Er zitten drie SDK's in de app. Niemand kan zeggen welke de conversiewaarde beheert.

Wat signal engineering oplost

Vijf lagen, in de volgorde waarin ik ze bouw.

• De eventlaag. Eén canonieke eventtaxonomie voor uw app, expliciet gemapt naar Meta standard events, Google-conversie-events, TikTok-events en uw MMP. Trial start, eerste betaling, verlenging, opzegging, terugbetaling. Elk met een waarde, een valuta en een ID.
• Server-side aanlevering. Meta's Conversions API voor app-events, TikTok's Events API en Google's opzet voor app-conversies, via uw MMP of Firebase, gekoppeld aan uw abonnementenbackend zodat verlengingen, terugbetalingen en trial-conversies de platformen bereiken, ook wanneer de app gesloten is. Gededupliceerd op event-ID zodat niets dubbel telt.
• Het iOS-conversiewaardeschema. De kleine waarde die Apple u laat terugsturen is het enige signaal na de install dat u krijgt voor gebruikers die tracking hebben geweigerd. Ik ontwerp het rond uw funnel en uw volume, zodat campagnes over Apples privacydrempels komen in plaats van niets terug te geven. Eén SDK beheert het. Schrijven twee SDK's het weg, dan wint de laatste aanroep, en op dit moment is dat meestal per ongeluk.
• Waardesignalen voor bidding. Aankoopwaarde, marge of voorspelde LTV, verstuurd naar elk platform, niet alleen Meta, en pas nadat ik heb gecontroleerd of de waarde daadwerkelijk correleert met wat gebruikers uiteindelijk betalen. Een slechte waarde leert het algoritme sneller de verkeerde gebruikers te kopen.
• De aansluiting. Eén maandelijkse vergelijking van platform-, MMP-, RevenueCat- en store-uitbetalingscijfers, met de verwachte verschillen erbij genoteerd, zodat u de volgende keer dat de cijfers uiteenlopen binnen vijf minuten weet of het structureel is of een bug.

Wat het na ATT niet oplost, en waarom ik dat zeg

Sinds iOS 14.5 kunnen gebruikers die App Tracking Transparency weigeren niet op gebruikersniveau worden geattribueerd. Apples SKAdNetwork en AdAttributionKit geven vertraagde, geaggregeerde postbacks terug zonder apparaat-ID, en ze houden bewust details achter bij campagnes met een laag volume. Geen enkele Conversions API-integratie, geen enkele MMP-functie en geen enkele tool voor attributieherstel verandert dat. Meta routeert die events via Aggregated Event Measurement. Google modelleert ze. TikTok modelleert ze.

Dus beloof ik geen deterministische attributie. Ik beloof dat de signalen die u wel kunt sturen kloppen, dat de platformen de best mogelijke input krijgen om op te optimaliseren, en dat u weet welke afwijkingen normaal zijn. Platform-ROAS en abonnementsomzet zullen elkaar na afloop van het werk nog steeds tegenspreken. Ze zullen elkaar tegenspreken om redenen die u kunt uitleggen. Als een leverancier iets anders beweert, vraag dan waar het gebruikers-ID vandaan komt.

Welk systeem rapporteert wat op iOS?

Vijf systemen tellen installs en conversies uit dezelfde iOS-campagnes. Spreken ze elkaar tegen, dan is niet per se een van de vijf fout. Ze tellen verschillende dingen, over verschillende vensters, met verschillende vertragingen. De tabel is gebaseerd op de eigen documentatie van elke leverancier, gecontroleerd op 29 september 2026.

Voor het iOS-beeld van Google moet u zelf werk verzetten. Voor Integrated Conversion Measurement noemt Google als vereisten een actieve iOS-appcampagne voor installs, de first_open-events en de events na de install van uw MMP geïmporteerd in Google Ads, meting op het apparaat met eventgegevens en een actuele MMP-SDK. Meting op het apparaat met eventgegevens vereist iOS 12 of hoger, de Google Analytics for Firebase SDK vanaf versie 11.14.0 en de Analytics-property die aan Google Ads is gekoppeld, en volgens Google is de meting inactief voor gebruikers in de EER, het Verenigd Koninkrijk en Zwitserland. Google Ads, de MMP en SKAN wijken dus per ontwerp van elkaar af, en Google zelf adviseert de ICM-weergave te lezen als u ICM heeft ingericht, en anders Google Ads of SKAN.De ICM-setup per integratieroute en hoe ik Google Ads, de MMP en SKAN met elkaar afstem hebben elk een eigen artikel.

Sommige verschillen hebben niets met definities te maken. Op een Google-account dat ik runde, stuurde het revenue-event $1 in plaats van $0 als een conversie geen waarde had, waardoor Google overal een te hoge ROAS rapporteerde, en op iOS het meest. Het is hetzelfde account als bij mijn test van biedstrategieën, en precies het soort bug dat de aansluiting moet opsporen.

Hoe werken SKAN 4 en AdAttributionKit voor Meta-campagnes op iOS?

Apple bepaalt wat er terugkomt: tot drie vertraagde postbacks per winnende advertentie, elk met een conversiewaarde die uw app op het apparaat schrijft, en minder detail naarmate de campagne kleiner is. Bij Meta gebruikt elke advertentieset voor apppromotie op iOS ofwel die SKAdNetwork-attributie ofwel Meta's eigen Aggregated Event Measurement, afhankelijk van waarvoor uw optimalisatie-event in aanmerking komt.

SKAN 4 en AdAttributionKit geven allebei drie postbackvensters terug, en alleen het eerste kan een fijnmazige waarde dragen. Apple valt terug op grof of op niets wanneer een campagne te klein is om de groep te beschermen. De eerste betaling van een proefperiode van 7 dagen valt op dag 7 of 8, in het tweede of derde venster, dagen later, als grove waarde. Daarom moet het schema rond uw funnel en uw volume worden ontworpen in plaats van uit een template gekopieerd, en daarom duwen te veel geo- en creative-splitsingen elke campagne tegelijk onder de drempel. In welk venster elke proefperiode valt en wie de waarde schrijft, staat in het artikel of SKAN de betaling na een gratis proefperiode kan meten.

Wie kan CAPI en event mapping voor Meta repareren?

Iemand die het hele eventpad beheert, van de app-SDK en de MMP tot de abonnementenbackend en Events Manager, omdat de meeste signaalbugs bij Meta zitten waar twee daarvan samenkomen. Op een retainer ben ik dat, met een attributie-engineer uit mijn netwerk voor het SDK- en serverwerk en één developer aan uw kant die wijzigingen kan uitrollen.

De Conversions API voor app-events verstuurt vanaf uw server dezelfde events die de SDK of de MMP vanaf het apparaat verstuurt, en Meta dedupliceert ze op event-ID. De functie ervan is volledigheid en waarde: verlengingen, terugbetalingen en conversies die plaatsvinden terwijl de app gesloten is, elk met een waarde en een valuta. Het herstelt geen attributie voor gebruikers die tracking hebben geweigerd; die events lopen nog steeds via Aggregated Event Measurement. De moeite waard, geen omweg. Komt een event bij Meta aan en komt het toch niet in aanmerking voor AEM, dan staan de controles per route in het artikel waarom events voor proefperiode en aankoop niet in aanmerking komen voor Meta AEM.

pLTV en value optimization

Een model voorspelt de waarde van elke nieuwe gebruiker op basis van de eerste dag of twee aan gedrag. Dat getal gaat naar het platform als aankoopwaarde, of wordt op iOS samengeperst tot de conversiewaarde. Het platform biedt vervolgens op gebruikers die lijken op uw voorspellingen met hoge waarde. Welk event en welke biedmodus bij welke app past staat uitgeschreven op basis van $1.2M aan Meta-spend.

Bij Videa was die laag, een op maat gemaakt CAPI-aankoopsignaal en voorspelde LTV in bidding, wat D0 ROAS van 20% naar een recordweek van 43% bracht. Een test van $606K maakte uit dat dagnulwaarde D28 ROAS beter voorspelt dan kosten per aankoop.

Op welk event moet u optimaliseren?

Dit zijn de drie vragen die ik stel, in deze volgorde, voordat ik dieper op een account ingaat. De volledige ladder, vanaf de install omhoog, staat in het artikel op welk event een abonnementsapp moet optimaliseren.

1. Halen betaalde events bij uw volume de leerdrempel van het platform? Meta's richtlijn is ongeveer 50 resultaten per advertentieset in de week na de laatste significante wijziging. Zo niet, optimaliseer dan op trial start plus een activatie-event. Zo ja, ga naar vraag 2.
2. Is de conversie van trial naar betaald gezond? Zo niet, blijf op trial start plus een activatie-event. Beide voorwaarden moeten gelden voordat u overstapt. Zo ja, stap over naar aankoop en ga naar vraag 3.
3. Correleert de waarde die u zou sturen met wat gebruikers uiteindelijk betalen? Zo niet, blijf op aankoop. Zo ja, stuur de waarde. Voor voorspelde LTV moeten er nog drie dingen kloppen: de voorspelling is gekalibreerd op cohorten die daadwerkelijk zijn gerijpt, er is genoeg volume, en het platform krijgt de voorspelling voordat het attributievenster sluit. Vroeg aangezet, optimaliseert het zelfverzekerd op de verkeerde gebruikers.

Platform-ROAS aansluiten op abonnementsomzet, over landen heen

Platformen tellen geattribueerde en gemodelleerde conversies binnen hun eigen venster, tegen brutoprijs, op de klikdatum. RevenueCat telt ontvangstbewijzen op de transactiedatum, na aftrek van terugbetalingen, in één valuta. Store-uitbetalingen komen binnen op een fiscale kalender, na aftrek van commissie en lokale belasting. Dat zijn structurele verschillen, en ze zijn te verwachten. Een verschil dat van maand tot maand van grootte verandert, heeft meestal een bug erachter: een dubbel aankoopevent, een valutamismatch, een waarde die het ene platform wel bereikt en het andere niet.

ROAS over meerdere landen voegt cohortrijping toe. Een land waarvan de gebruikers jaarlijks betalen, ziet er op dag 7 slechter uit en op dag 90 beter uit dan een land dat maandelijks verkoopt, dus vergelijk ik cohorten op gelijke leeftijd, in één valuta, na aftrek van commissie, voordat ik beslis welk land budget krijgt. De audit van $383K laat zien hoe dat er op een echt account uitziet, en hoeveel aankopen een ROAS nodig heeft voordat hij iets betekent bepaalt de ondergrens voor elke uitsplitsing.

Hoe het werk verloopt

Signal engineering maakt deel uit van de retainer, en het komt eerst. De doorlichting begint met de Growth Audit: wat elk platform op dit moment ontvangt, waarop het optimaliseert, en de viervoudige vergelijking met de verwachte afwijking erbij genoteerd. Na de doorlichting implementeren sommige teams de fixes zelf, aan de hand van de geprioriteerde lijst met de engineering-inspanning per item geschat. Anderen vragen mij om de accounts te runnen. Beide kan.

Voor SDK-werk en alles wat op uw servers draait haal ik een attributie-engineer uit mijn netwerk erbij. Ik ontwerp en beheer de laag; de technische handen zijn specialisten. U heeft één developer nodig die tijdens de opdracht wijzigingen kan uitrollen, en leestoegang tot Events Manager, de MMP, RevenueCat of uw abonnementenbackend, en de ad accounts.

Bent u nog niet toe aan een retainer maar wilt u wel de diagnose zonder de opdracht, dan behandelt een betaalde sessie van 90 minuten uw setup en wat er in welke volgorde gefixt moet worden. Die boekt u via dezelfde agenda als het kennismakingsgesprek.

Vragen die mensen stellen