Signal engineering er arbeidet med å sikre at Meta, Google og TikTok får rene, dedupliserte hendelser med riktig verdi fra appen din, backenden din og abonnementssystemet ditt, og at tallene som kommer tilbake, kan avstemmes mot reell omsetning. Det gir deg ikke tilbake iOS-attribusjon på brukernivå. Ingenting kan gjøre det. Det fikser den delen av problemet som er din, og det er det første jeg gjør på hver eneste konto.
Denne siden er for et team der value optimization sluttet å fungere, der dashbordene er uenige, eller der iOS-konverteringene kommer inn som antall uten verdi på seg. Den forteller hva som som regel er ødelagt, hva som fikses, hva som ikke kan fikses etter ATT, og testen for $606K som avgjorde hvilket signal som predikerer D28 ROAS.
Plattformfaktaene på denne siden er sjekket mot dokumentasjonen fra Apple, Meta, Google, TikTok, AppsFlyer og RevenueCat den 29. september 2026.
Du er sannsynligvis her fordi
Ingen av disse er mediekjøpsproblemer. De er signalproblemer, og de fleste av dem kan fikses.
- Meta rapporterer én ROAS, RevenueCat rapporterer halvparten av den, og finansavdelingen tror på ingen av dem. De vil aldri stemme overens, og ingen i teamet kan si hvorfor.
- SKAN-konverteringsverdiene dine kommer tilbake tomme på de fleste kampanjer, og ingen vet hvorfor.
- Meta skalerer fint. Google og TikTok stopper opp på det samme kreative.
- Du byttet til value optimization, og det ble verre.
- Prøvestarter er billige, og betalte konverteringer følger aldri etter.
- Tre SDK-er er i appen. Ingen kan si hvilken som eier konverteringsverdien.
Hva signal engineering fikser
Fem lag, i den rekkefølgen jeg bygger dem.
- Eventlaget. Én kanonisk event-taksonomi for appen din, eksplisitt kartlagt mot Metas standardhendelser, Googles konverteringshendelser, TikToks hendelser og MMP-en din. Prøvestart, første betaling, fornyelse, kansellering, refusjon. Hver med en verdi, en valuta og en ID.
- Serverside levering. Metas Conversions API for apphendelser, TikToks Events API og Googles oppsett for appkonvertering gjennom MMP-en din eller Firebase, koblet til abonnementssystemet ditt slik at fornyelser, refusjoner og prøvekonverteringer når plattformene selv når appen er lukket. Deduplisert med event-ID slik at ingenting telles to ganger.
- iOS-konverteringsverdiskjemaet. Den lille verdien Apple lar deg sende tilbake, er det eneste signalet du får etter installasjon for brukere som avslo sporing. Jeg designer det rundt trakten og volumet ditt, slik at kampanjer klarer Apples personvernterskler i stedet for å returnere ingenting. Én SDK eier det. Skriver to SDK-er til det, vinner det siste kallet, og akkurat nå er det som regel en tilfeldighet.
- Verdisignaler for budgivning. Kjøpsverdi, margin eller forventet LTV, sendt til alle plattformer, ikke bare Meta, og først når jeg har sjekket at verdien faktisk korrelerer med det brukerne ender opp med å betale. En dårlig verdi lærer algoritmen å kjøpe de feile brukerne raskere.
- Avstemmingsvisningen. Én månedlig sammenligning av plattform-, MMP-, RevenueCat- og butikkutbetalingstall med de forventede avvikene skrevet ned, slik at neste gang tallene ikke stemmer, vet du på fem minutter om det er strukturelt eller en feil.
Hva det ikke kan fikse etter ATT, og hvorfor jeg sier det
Siden iOS 14.5 kan ikke brukere som avslår App Tracking Transparency, attribueres på brukernivå. Apples SKAdNetwork og AdAttributionKit returnerer forsinkede, aggregerte postbacks uten enhets-ID, og de holder bevisst tilbake detaljer på kampanjer med lavt volum. Ingen Conversions API-integrasjon, ingen MMP-funksjon og ikke noe attribusjonsverktøy endrer på det. Meta ruter de hendelsene gjennom Aggregated Event Measurement. Google modellerer dem. TikTok modellerer dem.
Så jeg lover ikke deterministisk attribusjon. Jeg lover at signalene du kan kontrollere, er riktige, at plattformene får det best mulige grunnlaget å optimalisere mot, og at du vil vite hvilke avvik som er normale. Plattform-ROAS og abonnementsomsetning vil fortsatt være uenige etter at arbeidet er gjort. De vil være uenige av grunner du kan forklare. Sier en leverandør noe annet, spør dem hvor bruker-ID-en kommer fra.
Hvilket system rapporterer hva på iOS?
Fem systemer teller installasjoner og konverteringer fra de samme iOS-kampanjene, og når de er uenige, er det ikke sikkert at noen av dem tar feil. De teller ulike ting, over ulike vinduer, med ulike forsinkelser. Tabellen bygger på hver leverandørs egen dokumentasjon, sjekket den 29. september 2026.
Googles iOS-måling krever arbeid på din side. For Integrated Conversion Measurement krever Google en aktiv iOS-appkampanje for installasjoner, at first_open og hendelsene etter installasjon fra MMP-en din er importert i Google Ads, måling på enheten med hendelsesdata og en oppdatert MMP-SDK. Måling på enheten med hendelsesdata krever iOS 12 eller nyere, Google Analytics for Firebase SDK fra versjon 11.14.0 og en Analytics-egenskap koblet til Google Ads, og ifølge Google er den inaktiv for brukere i EØS, Storbritannia og Sveits. Google Ads, MMP-en og SKAN vil altså vise ulike tall, og det er meningen. Og Googles egen anbefaling er å lese ICM-visningen hvis du har implementert den, og ellers Google Ads eller SKAN. ICM-oppsettet for hver integrasjonsvei og hvordan jeg avstemmer Google Ads, MMP-en og SKAN har hver sin artikkel.
Noen avvik har ingenting med definisjoner å gjøre. På en Google-konto jeg drev, sendte inntektshendelsen $1 i stedet for $0 når en konvertering ikke hadde verdi, noe som blåste opp ROAS-en Google rapporterte over hele linjen, og mest på iOS. Det er kontoen bak testen min av budstrategier, og det er akkurat den typen feil avstemmingsvisningen finnes for å fange.
| System | Hva det teller | Forsinkelse | Vindu | Regionale begrensninger | Kilde |
|---|---|---|---|---|---|
| SKAdNetwork og AdAttributionKit (Apple) | Installasjoner kreditert den ene vinnende annonsen på tvers av alle nettverk. Opptil tre postbacks, hver med en konverteringsverdi appen skriver på enheten: en presis verdi fra 0 til 63 bare i den første, deretter en grov lav, middels eller høy, og ingen verdi for de minste mengdene. | Tilfeldig 24 til 48 timer etter at det første vinduet (dag 0 til 2) lukkes, og 24 til 144 timer etter det andre (dag 3 til 7) og det tredje (dag 8 til 35). | I AdAttributionKit som standard 30 dager for klikk og 1 dag for visninger; en app kan sette 1 til 30 og 1 til 7. | Tilgjengelig i EØS, Storbritannia og Sveits. En landkode kommer bare tilbake hvis landets mengde når Apples øverste nivå. | Apple, konverteringsvinduer; Apple, attribusjonsregler; Google, iOS-rapportering |
| Meta Aggregated Event Measurement | Installasjoner og apphendelser fra iOS 14.5 og nyere som Meta krediterer sine egne annonser, for hendelser som består Metas kvalifiseringssjekk. Siden 9. oktober 2024 sender Meta også denne rapporteringen til MMP-er. | Nesten i sanntid, ifølge Meta. | 1 dag etter klikk når annonsesettet optimaliserer for installasjoner; 1 eller 7 dager etter klikk for apphendelser eller verdi; i en Advantage+ appkampanje 1 dag etter klikk, pluss 1 dag etter visning for installasjoner. | Ingen nevnt på Metas attribusjonssider. | Meta, attribusjonsmetoder; Meta, AEM- og SKAdNetwork-rapportering |
| Modellerte konverteringer i Google Ads | Modellerte konverteringer på hendelsesnivå fra iOS-appkampanjer for installasjoner, bygget på IDFA, måling på enheten (ODM) og SKAdNetwork, i tabellene Kampanjer og Annonsegrupper. Klikk og engaged views, ingen view through. | Opptil 5 dager. | Som standard 30 dager for klikk og 2 dager for engaged views, begge kan justeres. | Dekker alle brukere, også i EØS, Storbritannia og Sveits. | Google, iOS-rapportering |
| Google ICM-krav i MMP-en | Probabilistiske installasjoner kreditert Googles iOS-appkampanjer for installasjoner, basert på IDFA og ODM-hendelsesdata. De vises i MMP-en, ikke i Google Ads-rapporteringen, som i stedet viser sine egne modellerte installasjoner. Klikk og engaged views, ingen view through. | Nærmere sanntid, bortsett fra noen MMP-forsinkelser i enkelte regioner, ifølge Google. | Lookback-vinduet for installasjoner som er satt i MMP-en: 6 timer til 30 dager ifølge Google, som nevner AppsFlyer som unntak. AppsFlyers egen standard for Google er 30 dager. | Inaktiv for iOS-brukere i EØS, Storbritannia og Sveits, fordi ODM-hendelsesdataene den trenger, er inaktive der. | Google, iOS-rapportering; Google, ICM; Google, ODM; AppsFlyer, avvik mot Google |
| App Store Connect | Førstegangsnedlastinger, nye nedlastinger, salg, proveny og abonnementshendelser, hver kreditert kilden som ble registrert da brukeren trykket for å laste ned: å søke eller bla i App Store, en henvisende app eller nettside, eller en kampanjelenke. Den ser den henvisende appen eller siden, ikke annonsekampanjen din, med mindre lenken hadde kampanjetokenet ditt med. Bruksdata kommer bare fra brukere som har godtatt å dele dem. | Dataene for en dag er komplette to dager senere, ifølge Apples dokumentasjon om rapporter. | Ikke noe attribusjonsvindu. Kilden blir hos brukeren til vedkommende laster ned appen på nytt manuelt. | Kan filtreres på region. Målinger vises bare når de ligger over Apples minimumsgrenser for personvern, for eksempel fem førstegangsnedlastinger. | Apple, anskaffelse; Apple, definisjoner av målinger; Apple, analyserapporter |
Hvordan fungerer SKAN 4 og AdAttributionKit for Meta-kampanjer på iOS?
Apple bestemmer hva som kommer tilbake: opptil tre forsinkede postbacks per vinnende annonse, hver med en konverteringsverdi appen din skriver på enheten, og mindre detalj jo mindre kampanjen er. Hos Meta bruker hvert annonsesett for apppromotering på iOS enten SKAdNetwork-attribusjonen eller Metas egen Aggregated Event Measurement, avhengig av hvilken optimaliseringshendelsen din kvalifiserer for.
SKAN 4 og AdAttributionKit returnerer begge tre postback-vinduer, og bare det første kan bære en presis verdi. Apple faller ned til grovt eller til ingenting når en kampanje er for liten til å beskytte mengden. Første betaling på en prøveperiode på 7 dager havner på dag 7 eller 8, i det andre eller tredje vinduet, som en grov verdi, dager senere. Det er derfor skjemaet må designes rundt trakten og volumet ditt, i stedet for å kopieres fra en mal, og hvorfor for mange oppdelinger på geo og kreativ presser hver eneste kampanje under terskelen samtidig. Hvilket vindu hver lengde på prøveperioden havner i, og hvem som skriver verdien, står i om SKAN kan måle betalingen etter en gratis prøveperiode.
| Vindu | Dager etter installasjon | Hvilken verdi det kan bære |
|---|---|---|
| Første | 0 til 2 | En presis verdi fra 0 til 63, eller en grov lav, middels eller høy |
| Andre | 3 til 7 | Kun grove verdier |
| Tredje | 8 til 35 | Kun grove verdier |
Hvem kan fikse CAPI og event-mapping for Meta?
Noen som eier hele hendelsesveien, fra app-SDK-en og MMP-en til abonnementssystemet og Events Manager, fordi de fleste signalfeil hos Meta sitter der to av dem møtes. På en retainer er det meg, med en attribusjonsingeniør fra nettverket mitt til SDK- og serverarbeidet og én utvikler på deres side som kan sende endringer.
Conversions API for apphendelser sender de samme hendelsene fra serveren din som SDK-en eller MMP-en sender fra enheten, og Meta dedupliserer dem etter event-ID. Jobben er fullstendighet og verdi: fornyelser, refusjoner og konverteringer som skjer når appen er lukket, hver med en verdi og en valuta. Det gjenoppretter ikke attribusjon for brukere som avslo sporing; de hendelsene flyter fortsatt gjennom Aggregated Event Measurement. Verdt å gjøre, ingen erstatning. Når en hendelse kommer fram til Meta og likevel ikke kvalifiserer for AEM, står sjekkene for hver integrasjonsvei i hvorfor hendelser for prøveperiode og kjøp ikke kvalifiserer for Meta AEM.
pLTV og value optimization
En modell predikerer hver ny brukers verdi ut fra de første ett til to dagenes atferd. Det tallet går til plattformen som kjøpsverdien, eller komprimeres på iOS til konverteringsverdien. Plattformen byr så på brukere som ligner dem modellen predikerer høy verdi for. Hvilken hendelse og hvilken budmodus som passer hvilken app, er skrevet opp fra $1,2M i Meta-forbruk.
Hos Videa var det laget, et skreddersydd CAPI-kjøpssignal og forventet LTV i budgivningen, som tok D0 ROAS fra 20% til en rekorduke på 43%. En test for $606K avgjorde at verdi på dag null predikerer D28 ROAS bedre enn kostnad per kjøp gjør.
Hvilken hendelse bør du optimalisere mot?
Dette er de tre spørsmålene jeg stiller, i denne rekkefølgen, før jeg går dypere inn i en konto. Hele stigen, fra installasjon og oppover, står i hvilken hendelse en abonnementsapp bør optimalisere mot.
- Klarer betalte hendelser plattformens læringsterskel ved ditt volum? Metas rettesnor er rundt 50 resultater per annonsesett i uken etter siste vesentlige endring. Hvis ikke, optimaliser mot prøvestart pluss en aktiveringshendelse. Hvis ja, gå til spørsmål 2.
- Er andelen fra prøve til betalende sunn? Hvis ikke, bli værende på prøvestart pluss en aktiveringshendelse. Begge betingelsene må være oppfylt før du bytter. Hvis ja, gå over til kjøp og videre til spørsmål 3.
- Korrelerer verdien du ville sendt, med det brukerne ender opp med å betale? Hvis ikke, bli værende på kjøp. Hvis ja, send verdien. Forventet LTV krever tre ting til: prediksjonen er kalibrert mot kohorter som faktisk har modnet, det er nok volum, og plattformen får den før attribusjonsvinduet lukkes. Slått på for tidlig, optimaliserer det mot feil brukere med stor selvtillit.
Å avstemme plattform-ROAS med abonnementsomsetning, på tvers av land
Plattformer teller attribuerte og modellerte konverteringer innenfor sitt eget vindu, til bruttopris, på klikkdatoen. RevenueCat teller kvitteringer på transaksjonsdatoen, etter refusjoner, i én valuta. Butikkutbetalinger kommer på en regnskapskalender, etter provisjon og lokal skatt. Det er strukturelle avvik, og de er forventet. Et avvik som endrer størrelse fra én måned til den neste, har som regel en feil bak seg: en duplisert kjøpshendelse, et valutamiss, en verdi som når én plattform og ikke den andre.
ROAS på tvers av land legger til kohortmodning. Et land der brukerne betaler årlig ser dårligere ut på dag 7 og bedre ut på dag 90 enn ett som selger månedlig, så jeg sammenligner kohorter ved lik alder, i én valuta, etter provisjon, før jeg avgjør hvilket land som får budsjett. Revisjonen for $383K er hvordan det ser ut på en reell konto, og hvor mange kjøp en ROAS trenger før den betyr noe setter grensen for hvert kutt.
Hvordan arbeidet foregår
Signal engineering er en del av retaineren, og det kommer først. Gjennomgangen starter med growth audit-en: hva hver plattform mottar akkurat nå, hva den optimaliserer mot, og en firedelt sammenligning med de forventede avvikene skrevet ned. Etter gjennomgangen implementerer noen team fiksene selv fra den prioriterte listen, med teknisk innsats anslått per punkt. Andre ber meg drifte kontoene. Begge deler er greit.
Til SDK-arbeid og alt som kjører på serverne deres, henter jeg inn en attribusjonsingeniør fra nettverket mitt. Jeg designer og eier laget; de tekniske hendene er spesialister. Du trenger én utvikler som kan sende endringer i løpet av samarbeidet, og lesetilgang til Events Manager, MMP-en, RevenueCat eller abonnementssystemet ditt, og annonsekontoene.
Er du tidligere i prosessen enn en retainer og vil ha diagnosen uten samarbeidet, dekker en betalt økt på 90 minutter oppsettet ditt og hva som bør fikses i hvilken rekkefølge. Den bookes gjennom den samme kalenderen som introsamtalen.
Hvem det passer for
- Abonnementsapper og mobilspill med paid UA på minst to av Meta, Google, TikTok og Apple Search Ads
- Team som avstemmer Meta, RevenueCat og MMP-en for hånd hver måned
- Apper som lener seg på iOS, der SKAN-postbacks bærer antall, men ingen verdi
- Enhver konto som er i ferd med å skalere forbruk på et signal som ikke er sjekket
Hva du får
- En revisjon av hver eneste hendelse appen og backenden din sender til hver plattform, med duplikater, manglende verdier, feil valutaer og testhendelser flagget
- En kartleggingsmatrise fra kanonisk hendelse til Meta-, Google-, TikTok- og MMP-hendelser
- Et iOS-konverteringsverdiskjema designet for trakten og volumet ditt, med postback-tidspunktene du bør forvente
- En anbefaling om hvilken hendelse hver plattform bør optimalisere mot ved ditt volum, og når du bør gå dypere
- En avstemming mellom plattform, abonnementssystem, MMP og butikkutbetalinger som du kan kjøre på nytt
- En prioritert fikseliste med teknisk innsats anslått per punkt
Spørsmål folk stiller
Fikser CAPI ATT?
Nei. CAPI er en leveringsvei fra serveren. Det gjør hendelsene dine mer fullstendige og lar deg sende rikere verdier. For brukere som avslo sporing, behandler Meta fortsatt de hendelsene gjennom aggregert måling. Det er verdt å gjøre. Det er ingen erstatning.
Erstatter SKAN MMP-en vår?
Nei. SKAN er én aggregert feed per nettverk. MMP-en samler den på tvers av nettverk, dedupliserer installasjoner som kreves av to nettverk, kartlegger konverteringsverdiene, legger til kostnad, og håndterer samtykkende brukere og kanaler SKAN ikke dekker. Kjører du mer enn ett nettverk, trenger du fortsatt en. Hvor mye av den organiske iOS-trafikken din som faktisk er betalt viser hva MMP-en alene går glipp av.
Erstatter Google ICM SKAN?
Nei. ICM gir MMP-en din probabilistiske installasjonskrav for Googles iOS-appkampanjer for installasjoner, bare fra klikk og engaged views, og ifølge Google ligger de dataene ikke i Google Ads-rapporteringen i dag. SKAdNetwork er fortsatt Apples egen feed på tvers av alle nettverk: den tar også med installasjoner etter visning (view through), den dekker EØS, Storbritannia og Sveits, der ICM er inaktiv, og Google Ads rapporterer installasjonene i en egen SKAdNetwork-rapport. Googles konverteringsmodellering bruker dessuten bare presise SKAN-verdier og støtter ikke grove verdier fra SKAN 4, så hendelsen du byr på, må fortsatt passe inn i det første vinduet. Googles sider, sjekket 29. september 2026: iOS-måling og rapportering og SKAdNetwork-skjemaet for konverteringsverdier.
Kan RevenueCat skrive SKAN-konverteringsverdier?
Nei. RevenueCats dokumentasjon for Meta-integrasjonen sier at RevenueCat verken konfigurerer SKAN eller AEM og ikke oppdaterer SKAN-konverteringsverdier, og Singular-dokumentasjonen sier at serverhendelsene ikke kan endre dem. Apple dokumenterer oppdateringer av konverteringsverdien som kall appen gjør i hvert konverteringsvindu, så det er din egen kode eller en SDK i appen som skriver, for eksempel Meta-SDK-en eller MMP-ens. RevenueCats råd er én oppdaterer, så verdiene ikke kolliderer. Sjekket 29. september 2026.
Hvorfor kvalifiserer ikke iOS-hendelsen min for Meta AEM?
Metas feilsøkingsside nevner de vanlige årsakene: hendelsen kommer gjennom en annen integrasjon enn installasjonshendelsen din, eller gjennom flere integrasjoner samtidig; integrasjonen sender IP-adresser ujevnt eller ikke i det hele tatt; det var ikke nok signaler de siste 30 dagene; eller Facebook SDK for iOS er eldre enn 16.0.0, eller MMP-SDK-en er utdatert. AppsFlyer legger til at Meta for hendelser fra server til server trenger både IP-adressen og IDFV i payloaden; hvorvidt dere sender dem for brukere som avslo sporing, er en personvernbeslutning for teamet deres. Etter at du har valgt en annen integrasjon i Events Manager, kan Meta bruke opptil 7 dager på å sjekke på nytt. En levering som RevenueCat eller en MMP melder som vellykket, betyr at Meta tok imot hendelsen, ikke at den kvalifiserer. Sjekket 29. september 2026.
Hvorfor stemmer ikke plattform-ROAS-en vår med RevenueCat?
Fordi de måler ulike ting. Plattformer teller attribuerte og modellerte konverteringer innenfor sitt eget vindu, til bruttopris, på klikkdatoen. RevenueCat teller kvitteringer på transaksjonsdatoen, etter refusjoner. Butikkutbetalinger kommer på en regnskapskalender, etter provisjon og skatt. De tre sammenligningene som er verdt å kjøre, og hva hver av dem svarer på, er skrevet opp.
Hvordan fungerer pLTV-budgivning?
En modell predikerer hver ny brukers verdi ut fra de første ett til to dagenes atferd. Det tallet går til plattformen som kjøpsverdien, eller komprimeres på iOS til konverteringsverdien, og plattformen byr på brukere som ligner dem modellen predikerer høy verdi for. Det hjelper bare hvis prediksjonen er kalibrert, det er nok volum, og plattformen får den før attribusjonsvinduet lukkes.
Bør vi optimalisere for prøvestart eller kjøp?
Det avhenger av volum og andelen som går fra prøve til betalende. Ved lavt volum er kjøpshendelser for få og forsinkede, så prøvestart pluss en aktiveringshendelse er som regel riktig. Når betalte hendelser klarer plattformens læringsterskel og andelen fra prøve til betalende er sunn, går du over til kjøp eller verdi. De fleste apper blir stående på prøvestart lenger enn de burde. ROAS eller kjøpsoptimalisering på Meta dekker budsiden.
iOS-attribusjonen ser ødelagt ut. Er den det?
Sannsynligvis ikke. Forsinkede postbacks, tomme verdier på små kampanjer og avvik mellom plattform og MMP er alle forventet. De reelle feilene er som regel en annen SDK som overskriver konverteringsverdien, et skjema som ikke matcher MMP-en, eller for mange oppdelinger på geo og kreativ som presser hver kampanje under personvernterskelen.
Er signal engineering det samme som å sette opp MMP-en?
Nei. MMP-en registrerer hva som skjedde. Signal engineering avgjør hva annonseplattformene får vite, og i hvilken form, slik at de optimaliserer mot betalere. De fleste kontoer har MMP-en installert og signalet feil.
Hvor lang tid tar signal engineering?
Revisjonen tar dager. Fiksene begynner å mate algoritmene i løpet av uker, som er raskere enn noen kreativ dom, og det er derfor dette kommer først. Growth audit-en er der det starter, og den kan bookes for seg selv, uansett forbruksnivå.
Krever signal engineering teknisk arbeid fra min side?
Noe, for SDK-endringer og alt som kjører på serverne deres, og jeg henter inn en attribusjonsingeniør fra nettverket mitt til å gjøre det med teamet ditt. Du trenger én utvikler som kan sende endringer i løpet av samarbeidet. Designet og eierskapet til laget blir hos meg.
Er det et minimumsforbruk?
Retainere er bygget for apper som allerede bruker rundt $100K i måneden eller mer på paid UA, eller er finansiert for å komme dit. Under det er growth audit-en tilgjengelig uansett forbruksnivå, og en betalt økt på 90 minutter dekker diagnosen for seg selv. Svært små kampanjer klarer ikke Apples personvernterskler uansett hvor rent signalet er, og det sier jeg på samtalen.
Kilder
- App Tracking Transparency Apple Developer Documentation. Sjekket 29. september 2026.
- AdAttributionKit Apple Developer Documentation. Sjekket 29. september 2026.
- Receiving postbacks in multiple conversion windows Apple Developer Documentation, SKAdNetwork. De tre vinduene og de grove og presise verdiene. Sjekket 29. september 2026.
- Receiving postbacks in multiple conversion windows (AdAttributionKit) Apple Developer Documentation. Vinduer, tilfeldige forsinkelser på postbacks, datanivåer for postbacks og landkoden. Sjekket 29. september 2026.
- Configuring attribution rules for your app Apple Developer Documentation. Standardvinduer og justerbare vinduer for klikk og visninger. Sjekket 29. september 2026.
- App ad attribution overview Apple Ads Help. Apple Ads registrerte seg med AdAttributionKit 10. april 2025. Sjekket 29. september 2026.
- Acquisition App Store Connect Analytics Help. Kildetyper, og hvordan nedlastinger, salg og abonnementer krediteres dem. Sjekket 29. september 2026.
- Metric definitions App Store Connect Analytics Help. Nedlastingsmålinger og minimumsgrensene deres. Sjekket 29. september 2026.
- Analytics Reports API App Store Connect Analytics Help. Fullstendighet i dataene og personvernterskler. Sjekket 29. september 2026.
- Conversions API for App Events Meta for Developers. Sjekket 29. september 2026.
- Key concepts for Meta's Aggregated Event Measurement and Apple's SKAdNetwork Meta Business Help Center. Sjekket 29. september 2026.
- About campaign attribution methods Meta Business Help Center. AEM-attribusjonsvinduer for apppromoteringskampanjer på iOS 14 og nyere. Sjekket 29. september 2026.
- Ads Manager reporting differences between Meta's Aggregated Event Measurement and Apple's SKAdNetwork Meta Business Help Center. Forsinkelser i rapporteringen, og AEM-rapportering sendt til MMP-er fra 9. oktober 2024. Sjekket 29. september 2026.
- Troubleshoot issues with app eligibility for Aggregated Event Measurement Meta Business Help Center. Sjekket 29. september 2026.
- Set up mobile app conversion tracking Google Ads Help. Sjekket 29. september 2026.
- About bidding in App campaigns Google Ads Help. Target ROAS bruker konverteringsverdier fra hendelser i appen. Sjekket 29. september 2026.
- Understanding iOS App campaign measurement and reporting Google Ads Help. Modellerte konverteringer, ICM og SKAdNetwork sammenlignet. Sjekket 29. september 2026.
- About Integrated Conversion Measurement for App Campaigns Google Ads Help. Krav for iOS. Sjekket 29. september 2026.
- About on-device conversion measurement for iOS App campaigns Google Ads Help. Krav, og inaktiv for brukere i EØS, Storbritannia og Sveits. Sjekket 29. september 2026.
- Set up your SKAdNetwork conversion value schema Google Ads Help. Googles modellering bruker bare presise verdier. Sjekket 29. september 2026.
- About App Event Optimization TikTok Ads Manager Help Center, oppdatert mai 2025. Sjekket 29. september 2026.
- Events API TikTok Business Help Center, oppdatert april 2025. Hendelser fra serveren på tvers av nett, app og offline. Sjekket 29. september 2026.
- Google Ads (AdWords): FAQ and discrepancies AppsFlyer Help Center, redigert 16. mars 2026. Google Ads viser sine egne modellerte installasjoner, AppsFlyer viser ICM-krav. Sjekket 29. september 2026.
- Meta Ads Aggregate Event Measurement (AEM) for iOS AppsFlyer Help Center, redigert 25. mai 2026. IP-adresse og IDFV kreves på hendelser fra server til server. Sjekket 29. september 2026.
- SKAN modeled data AppsFlyer Help Center. En MMP som beskriver hvordan den modellerer verdiene Apple holder tilbake; nøyaktigheten i den modelleringen er leverandørens egen påstand. Sjekket 29. september 2026.
- Meta Ads integration RevenueCat-dokumentasjon. Konfigurerer verken SKAN eller AEM og oppdaterer ikke SKAN-konverteringsverdier. Sjekket 29. september 2026.
- Singular integration RevenueCat-dokumentasjon. Serverhendelser kan ikke endre SKAdNetwork-konverteringsverdier. Sjekket 29. september 2026.