Signal engineering är arbetet med att se till att Meta, Google och TikTok får rena, deduplicerade events med rätt värde från din app, din backend och ditt prenumerationssystem, och att siffrorna som kommer tillbaka går att stämma av mot verklig omsättning. Det ger dig inte tillbaka attribution på användarnivå på iOS. Ingenting gör det. Det fixar den del av problemet som är din, och det är det första jag gör på varje konto.
Den här sidan är för ett team vars value optimization slutade fungera, vars dashboards inte är överens, eller vars iOS-konverteringar kommer in som antal utan värde på sig. Den beskriver vad som oftast går sönder, vad som går att fixa, vad som inte går att fixa efter ATT, och testet för 606 000 $ som avgjorde vilken signal som förutsäger D28 ROAS.
Plattformsfakta på den här sidan har kontrollerats mot Apples, Metas, Googles, TikToks, AppsFlyers och RevenueCats dokumentation den 29 september 2026.
Du är förmodligen här för att
Inget av det här är mediainköpsproblem. Det är signalproblem, och de flesta går att fixa.
- Meta rapporterar en ROAS, RevenueCat rapporterar hälften av den, och ekonomiavdelningen tror inte på någon av dem. De kommer aldrig att stämma överens, och ingen i teamet kan säga varför.
- Dina conversion values från SKAN kommer tillbaka tomma på de flesta kampanjer och ingen vet varför.
- Meta skalar fint. Google och TikTok stannar upp på samma kreativa material.
- Du bytte till value optimization och det blev sämre.
- Provperiodstarter är billiga och betalande konverteringar följer aldrig efter.
- Tre SDK:er finns i appen. Ingen kan säga vilken som äger conversion value.
Vad signal engineering fixar
Fem lager, i den ordning jag bygger dem.
- Eventlagret. En kanonisk eventtaxonomi för din app, mappad uttryckligen till Metas standardevents, Googles conversion events, TikToks events och ditt MMP. Provperiodstart, första betalning, förnyelse, uppsägning, återbetalning. Var och en med ett värde, en valuta och ett ID.
- Serverbaserad leverans. Metas Conversions API för app-events, TikToks Events API och Googles konverteringsuppsättning för appar genom ditt MMP eller Firebase, kopplat till din prenumerationsbackend så att förnyelser, återbetalningar och provperiodskonverteringar når plattformarna även när appen är stängd. Deduplicerat på event-ID så att inget räknas dubbelt.
- iOS conversion value-schemat. Det lilla värdet Apple låter dig skicka tillbaka är den enda signalen efter installationen du får för användare som avböjde spårning. Jag utformar det utifrån din tratt och din volym, så att kampanjer klarar Apples sekretesströsklar istället för att inte returnera något alls. En SDK äger det. När två SDK:er skriver till det vinner det senaste anropet, och just nu är det oftast en olyckshändelse.
- Värdesignaler för budgivning. Köpvärde, marginal eller predikterat LTV, skickat till varje plattform, inte bara Meta, och först när jag har kontrollerat att värdet faktiskt korrelerar med vad användarna sedan betalar. Ett dåligt värde lär algoritmen att köpa fel användare snabbare.
- Avstämningsvyn. En månatlig jämförelse av siffror från plattform, MMP, RevenueCat och butiksutbetalningar, med de förväntade avvikelserna nedskrivna, så att du nästa gång siffrorna inte stämmer vet inom fem minuter om det är strukturellt eller en bugg.
Vad det inte kan fixa efter ATT, och varför jag säger det
Sedan iOS 14.5 kan användare som avböjer App Tracking Transparency inte attribueras på användarnivå. Apples SKAdNetwork och AdAttributionKit returnerar fördröjda, aggregerade postbacks utan enhets-ID, och de håller avsiktligt tillbaka detaljer på lågvolymkampanjer. Ingen Conversions API-integration, ingen MMP-funktion och inget verktyg för attributionsåterställning ändrar på det. Meta dirigerar de eventen genom Aggregated Event Measurement. Google modellerar dem. TikTok modellerar dem.
Så jag lovar inte deterministisk attribution. Jag lovar att signalerna du kan kontrollera är korrekta, att plattformarna får bästa möjliga underlag att optimera mot, och att du kommer veta vilka avvikelser som är normala. Plattforms-ROAS och prenumerationsomsättning kommer fortfarande inte stämma överens efter att arbetet är klart. De kommer inte stämma överens av skäl du kan förklara. Om en leverantör säger något annat, fråga dem var användar-ID:t kommer ifrån.
Vilket system rapporterar vad på iOS?
Fem system räknar installationer och konverteringar från samma iOS-kampanjer, och när de inte stämmer överens behöver inget av dem ha fel. De räknar olika saker, över olika fönster, med olika fördröjningar. Tabellen bygger på varje leverantörs egen dokumentation, kontrollerad den 29 september 2026.
Googles bild av iOS kräver arbete på din sida. För Integrated Conversion Measurement kräver Google en aktiv iOS-appkampanj för installationer, first_open och eventen efter installationen från ditt MMP importerade i Google Ads, mätning på enheten med eventdata, och en aktuell MMP-SDK. Mätning på enheten med eventdata kräver iOS 12 eller senare, Google Analytics for Firebase SDK från version 11.14.0 och en Analytics-egendom kopplad till Google Ads, och enligt Google är den inaktiv för användare i EES, Storbritannien och Schweiz. Google Ads, MMP:et och SKAN stämmer alltså inte överens av konstruktion, och Googles egen rekommendation är att läsa ICM-vyn om du har implementerat den, och annars Google Ads eller SKAN. ICM-uppsättningen för varje integrationsväg och hur jag stämmer av Google Ads, MMP:et och SKAN har var sin artikel.
Vissa avvikelser har inget med definitioner att göra. På ett Google-konto jag skötte skickade intäktseventet 1 $ i stället för 0 $ när en konvertering saknade värde, vilket blåste upp den ROAS som Google rapporterade överallt, och mest på iOS. Det är kontot bakom mitt test av budstrategier, och det är precis den sortens bugg som avstämningsvyn finns till för att fånga.
| System | Vad det räknar | Fördröjning | Fönster | Regionala begränsningar | Källa |
|---|---|---|---|---|---|
| SKAdNetwork och AdAttributionKit (Apple) | Installationer krediterade den enda vinnande annonsen över alla nätverk. Upp till tre postbacks, var och en med ett conversion value som appen skriver på enheten: ett fint värde från 0 till 63 bara i den första, därefter ett grovt low, medium eller high, och inget värde alls för de minsta grupperna. | Slumpmässigt 24 till 48 timmar efter att det första fönstret (dag 0 till 2) har stängts, och 24 till 144 timmar efter det andra (dag 3 till 7) och det tredje (dag 8 till 35). | I AdAttributionKit som standard 30 dagar för klick och 1 dag för visningar; en app kan ställa in 1 till 30 och 1 till 7. | Tillgängligt i EES, Storbritannien och Schweiz. En landskod kommer bara tillbaka när landets grupp når Apples högsta nivå. | Apple, konverteringsfönster; Apple, attributionsregler; Google, iOS-rapportering |
| Meta Aggregated Event Measurement | Installationer och app-events från iOS 14.5 och senare som Meta krediterar sina egna annonser, för events som klarar Metas behörighetskontroll. Sedan den 9 oktober 2024 skickar Meta även den här rapporteringen till MMP:er. | Nästan i realtid, enligt Meta. | 1 dag efter klick när annonsuppsättningen optimerar för installationer; 1 eller 7 dagar efter klick för app-events eller värde; i en Advantage+ appkampanj 1 dag efter klick, plus 1 dag efter visning för installationer. | Inga nämns på Metas attributionssidor. | Meta, attributionsmetoder; Meta, AEM- och SKAdNetwork-rapportering |
| Modellerade konverteringar i Google Ads | Modellerade konverteringar på eventnivå från iOS-appkampanjer för installationer, baserade på IDFA, mätning på enheten (ODM) och SKAdNetwork, i tabellerna Kampanjer och Annonsgrupper. Klick och engaged views, ingen view through. | Upp till 5 dagar. | Som standard 30 dagar för klick och 2 dagar för engaged views, och båda går att ändra. | Täcker alla användare, även i EES, Storbritannien och Schweiz. | Google, iOS-rapportering |
| Googles ICM-anspråk i MMP:et | Probabilistiska installationer krediterade Googles iOS-appkampanjer för installationer, baserade på IDFA och eventdata från ODM. De syns i MMP:et, inte i Google Ads-rapporteringen, som i stället visar sina egna modellerade installationer. Klick och engaged views, ingen view through. | Nära realtid, bortsett från vissa MMP-fördröjningar i vissa regioner, enligt Google. | Det lookbackfönster för installationer som är inställt i MMP:et, 6 timmar till 30 dagar enligt Google, som nämner AppsFlyer som undantag; AppsFlyers egen standard för Google är 30 dagar. | Inaktivt för iOS-användare i EES, Storbritannien och Schweiz, eftersom de ODM-eventdata det behöver är inaktiva där. | Google, iOS-rapportering; Google, ICM; Google, ODM; AppsFlyer, avvikelser mot Google |
| App Store Connect | Förstagångsnedladdningar, omnedladdningar, försäljning, intäkter och prenumerationsevents, var och en tillskriven den källa som registrerades när användaren tryckte på ladda ner: sökning eller bläddring i App Store, en hänvisande app eller webbplats, eller en kampanjlänk. Den visar den hänvisande appen eller sajten, inte din annonskampanj, om inte länken innehöll din kampanjtoken. Användningsdata kommer bara från användare som har gått med på att dela den. | En dags data är komplett två dagar senare, enligt Apples dokumentation om rapporter. | Inget attributionsfönster. Källan stannar hos användaren tills användaren laddar ner appen igen manuellt. | Går att filtrera per område. Mätvärden syns bara över Apples integritetsminimum, till exempel fem förstagångsnedladdningar. | Apple, förvärv; Apple, definitioner av mätvärden; Apple, analysrapporter |
Hur fungerar SKAN 4 och AdAttributionKit för Meta-kampanjer på iOS?
Apple bestämmer vad som kommer tillbaka: upp till tre fördröjda postbacks per vinnande annons, var och en med ett conversion value som din app skriver på enheten, och ju mindre kampanjen är, desto mindre detalj. Hos Meta använder varje annonsuppsättning för appmarknadsföring på iOS antingen SKAdNetwork-attribution eller Metas egen Aggregated Event Measurement, beroende på vilken ditt optimeringsevent är behörigt för.
SKAN 4 och AdAttributionKit returnerar båda tre postbackfönster, och bara det första kan bära ett fint värde. Apple går ner till grovt eller till inget alls när en kampanj är för liten för att skydda gruppen. Den första betalningen efter en provperiod på 7 dagar landar dag 7 eller 8, i det andra eller tredje fönstret, som ett grovt värde, dagar senare. Det är därför schemat måste utformas utifrån din tratt och din volym och inte kopieras från en mall, och varför för många geo- och kreativa uppdelningar trycker ner varje kampanj under tröskeln samtidigt. Vilket fönster varje längd på provperioden hamnar i, och vem som skriver värdet, står i om SKAN kan mäta betalningen efter en gratis provperiod.
| Fönster | Dagar efter installation | Vilket värde det kan bära |
|---|---|---|
| Första | 0 till 2 | Ett fint värde från 0 till 63, eller ett grovt low, medium eller high |
| Andra | 3 till 7 | Bara grova värden |
| Tredje | 8 till 35 | Bara grova värden |
Vem kan fixa CAPI och event mapping för Meta?
Någon som äger hela eventvägen, från appens SDK och MMP:et till prenumerationsbackend och Events Manager, eftersom de flesta signalbuggar hos Meta sitter där två av dem möts. I ett retainer är det jag, med en attributionsingenjör från mitt nätverk för SDK- och serverarbetet och en utvecklare på din sida som kan skicka ändringar.
Conversions API för app-events skickar samma events från din server som SDK:n eller MMP:et skickar från enheten, och Meta deduplicerar dem på event-ID. Dess jobb är fullständighet och värde: förnyelser, återbetalningar och konverteringar som sker när appen är stängd, var och en med ett värde och en valuta. Det återställer inte attribution för användare som avböjde spårning, de eventen flödar fortfarande genom Aggregated Event Measurement. Värt att göra, ingen genväg. När ett event når Meta och ändå är markerat som inte behörigt för AEM står kontrollerna för varje väg i varför event för provperiod och köp inte är behöriga för Meta AEM.
pLTV och value optimization
En modell förutsäger varje ny användares värde utifrån de första dagarnas beteende. Den siffran går till plattformen som köpvärdet, eller komprimeras på iOS till conversion value. Plattformen budar sedan på användare som liknar dina högvärdesprediktioner. Vilket event och vilket budgivningsläge som passar vilken app är beskrivet utifrån 1,2M$ i Meta-spend.
Hos Videa var det lagret, en skräddarsydd CAPI-köpsignal och predikterat LTV i budgivningen, det som tog D0 ROAS från 20% till en rekordvecka på 43%. Ett test för 606 000 $ avgjorde att dag noll-värde förutsäger D28 ROAS bättre än kostnad per köp gör.
Vilket event ska du optimera mot?
Det här är de tre frågorna jag ställer, i den här ordningen, innan jag går djupare i ett konto. Alla steg, från installation och uppåt, finns i vilket event en prenumerationsapp ska optimera mot.
- Klarar betalande events plattformens inlärningströskel vid din volym? Metas riktmärke är ungefär 50 resultat per annonsuppsättning under veckan efter den senaste betydande ändringen. Om inte, optimera mot provperiodstart plus ett aktiveringsevent. Om ja, gå till fråga 2.
- Är konverteringen från provperiod till betalande hälsosam? Om inte, stanna på provperiodstart plus ett aktiveringsevent. Båda villkoren måste vara uppfyllda innan du byter. Om ja, byt till köp och gå till fråga 3.
- Korrelerar värdet du skulle skicka med vad användarna sedan betalar? Om inte, stanna på köp. Om ja, skicka värdet. Predikterat LTV kräver tre saker till: prediktionen är kalibrerad mot kohorter som faktiskt har mognat, det finns tillräcklig volym, och plattformen får den innan attributionsfönstret stänger. Aktiverat för tidigt optimerar det mot fel användare med stort självförtroende.
Att stämma av plattforms-ROAS mot prenumerationsomsättning, över länder
Plattformar räknar attribuerade och modellerade konverteringar inom sitt eget fönster, till bruttopris, på klickdatumet. RevenueCat räknar kvitton på transaktionsdatumet, netto efter återbetalningar, i en valuta. Butiksutbetalningar kommer enligt en räkenskapskalender, netto efter provision och lokal skatt. Det är strukturella avvikelser, och de är förväntade. En avvikelse som ändrar storlek från en månad till nästa har oftast en bugg bakom sig: ett duplicerat köpevent, en valutamismatch, ett värde som når en plattform men inte den andra.
ROAS över flera länder lägger till kohortmognad. Ett land vars användare betalar årsvis ser sämre ut vid dag 7 och bättre ut vid dag 90 än ett som säljer månadsvis, så jag jämför kohorter vid samma ålder, i en valuta, netto efter provision, innan jag bestämmer vilket land som får budget. Granskningen för 383 000 $ visar hur det ser ut på ett verkligt konto, och hur många köp en ROAS behöver innan den betyder något sätter golvet för varje uppdelning.
Hur arbetet går till
Signal engineering ingår i retainer, och det kommer först. Läsningen börjar med growth audit: vad varje plattform får in just nu, vad den optimerar mot, och fyrvägsjämförelsen med den förväntade avvikelsen nedskriven. Efter läsningen implementerar vissa team fixarna själva utifrån den prioriterade listan, med utvecklingsinsatsen uppskattad per punkt. Vissa ber mig sköta kontona. Båda fungerar.
För SDK-arbete och allt som körs på dina servrar tar jag in en attributionsingenjör från mitt nätverk. Jag designar och äger lagret, det tekniska utförandet sköts av specialister. Du behöver en utvecklare som kan skicka ändringar under uppdraget, och läsbehörighet till Events Manager, MMP:et, RevenueCat eller din prenumerationsbackend, och annonskontona.
Om du är tidigare än ett retainer och vill ha diagnosen utan uppdraget täcker en betald 90-minuterssession din uppsättning och vad som ska fixas i vilken ordning. Den bokas genom samma kalender som introsamtalet.
Vem det är för
- Prenumerationsappar och mobilspel med paid UA på minst två av Meta, Google, TikTok och Apple Search Ads
- Team som stämmer av Meta, RevenueCat och MMP:et för hand varje månad
- Appar som lutar sig mot iOS, där SKAN-postbacks bär antal men inget värde
- Alla konton på väg att skala spend på en signal som inte har kontrollerats
Vad du får
- En granskning av varje event din app och backend skickar till varje plattform, med dubbletter, saknade värden, fel valutor och testevents flaggade
- En mappningsmatris från kanoniskt event till Metas, Googles, TikToks och MMP:ets events
- Ett iOS conversion value-schema utformat för din tratt och volym, med den timing för postbacks du bör förvänta dig
- En rekommendation om vilket event varje plattform ska optimera mot vid din volym, och när det är dags att gå djupare
- En avstämning mellan plattform, prenumerationsbackend, MMP och butiksutbetalningar som du kan köra om
- En prioriterad fixlista med utvecklingsinsatsen uppskattad per punkt
Vanliga frågor
Fixar CAPI ATT?
Nej. CAPI är en serverbaserad leveransväg. Den gör dina events mer fullständiga och låter dig skicka rikare värden. För användare som avböjde spårning behandlar Meta fortfarande de eventen genom aggregerad mätning. Det är värt att göra. Det är ingen genväg.
Ersätter SKAN vårt MMP?
Nej. SKAN är ett aggregerat flöde per nätverk. MMP:et samlar in det över nätverk, deduplicerar installationer som två nätverk gör anspråk på, mappar conversion values, lägger till kostnad, och hanterar samtyckta användare och kanaler SKAN inte täcker. Kör du mer än ett nätverk behöver du fortfarande ett MMP. Hur mycket av din organiska iOS-trafik som egentligen är betald visar vad MMP:et ensamt missar.
Ersätter Google ICM SKAN?
Nej. ICM ger ditt MMP probabilistiska installationsanspråk för Googles iOS-appkampanjer för installationer, bara från klick och engaged views, och enligt Google finns de inte i Google Ads-rapporteringen i dag. SKAdNetwork är fortfarande Apples eget flöde över alla nätverk: det inkluderar även installationer efter visning (view through), det täcker EES, Storbritannien och Schweiz, där ICM är inaktivt, och Google Ads rapporterar dess installationer i en separat SKAdNetwork-rapport. Googles konverteringsmodellering använder dessutom bara fina SKAN-värden och stöder inte grova värden från SKAN 4, så eventet du budar på måste fortfarande få plats i det första fönstret. Googles sidor, kontrollerade 29 september 2026: iOS-mätning och rapportering och SKAdNetwork-schemat för conversion values.
Kan RevenueCat skriva conversion values i SKAN?
Nej. RevenueCats dokumentation om Meta-integrationen säger att RevenueCat varken konfigurerar SKAN eller AEM och inte uppdaterar conversion values i SKAN, och i Singular-dokumentationen står att RevenueCats serverevents inte kan ändra dem. Apple dokumenterar uppdateringar av conversion value som anrop appen gör under varje konverteringsfönster, så det är din egen kod eller en SDK i appen som skriver, till exempel Metas SDK eller MMP:ets. RevenueCats råd är en enda uppdaterare, så att värdena inte krockar. Kontrollerad 29 september 2026.
Varför är mitt iOS-event inte behörigt för Meta AEM?
Metas felsökningssida nämner de vanliga orsakerna: eventet kommer via en annan integration än ditt installationsevent, eller via flera integrationer samtidigt; integrationen skickar IP-adresser ojämnt eller inte alls; det fanns inte tillräckligt med signaler de senaste 30 dagarna; eller så är Facebook SDK för iOS äldre än 16.0.0 eller MMP-SDK:n inaktuell. AppsFlyer lägger till att Meta behöver både IP-adressen och IDFV i payloaden för events från server till server. Huruvida de ska skickas för användare som avböjde spårning är ett integritetsbeslut för ditt team. När du har valt en annan integration i Events Manager kan Meta behöva upp till 7 dagar för att kontrollera på nytt. En leverans som RevenueCat eller ett MMP rapporterar som lyckad betyder att Meta tog emot eventet, inte att det är behörigt. Kontrollerad 29 september 2026.
Varför stämmer inte vår plattforms-ROAS med RevenueCat?
Eftersom de mäter olika saker. Plattformar räknar attribuerade och modellerade konverteringar inom sitt eget fönster, till bruttopris, på klickdatumet. RevenueCat räknar kvitton på transaktionsdatumet, netto efter återbetalningar. Butiksutbetalningar kommer enligt en räkenskapskalender, netto efter provision och skatt. De tre jämförelserna som är värda att köra, och vad var och en svarar på, finns beskrivna.
Hur fungerar pLTV-budgivning?
En modell förutsäger varje ny användares värde utifrån de första dagarnas beteende. Den siffran går till plattformen som köpvärdet, eller komprimeras på iOS till conversion value, och plattformen budar på användare som liknar dina högvärdesprediktioner. Det hjälper bara om prediktionen är kalibrerad, det finns tillräcklig volym, och plattformen får den innan attributionsfönstret stänger.
Ska vi optimera för provperiodstart eller köp?
Det beror på volym och konverteringsgrad från provperiod till betalande. Vid låg volym är köpevents för glesa och fördröjda, så provperiodstart plus ett aktiveringsevent är oftast rätt. När betalande events klarar plattformens inlärningströskel och konverteringen från provperiod till betalande är hälsosam, gå vidare till köp eller värde. De flesta appar stannar på provperiodstart längre än de borde. ROAS eller purchase optimization på Meta täcker budgivningssidan.
iOS-attributionen ser trasig ut. Är den det?
Förmodligen inte. Fördröjda postbacks, tomma värden på små kampanjer och avvikelser mellan plattform och MMP är alla förväntade. De verkliga buggarna är oftast en andra SDK som skriver över conversion value, ett schema som inte matchar MMP:et, eller för många geo- och kreativa uppdelningar som trycker ner varje kampanj under sekretesströskeln.
Är signal engineering samma sak som att sätta upp MMP:et?
Nej. MMP:et registrerar vad som hände. Signal engineering avgör vad annonsplattformarna får veta, och i vilken form, så att de optimerar mot betalare. De flesta konton har MMP:et installerat och signalen fel.
Hur lång tid tar signal engineering?
Granskningen tar dagar. Fixarna börjar mata algoritmerna inom några veckor, vilket är snabbare än något kreativt utslag, och det är därför det här kommer först. Growth audit är där det börjar, och den kan bokas fristående oavsett spendnivå.
Kräver signal engineering utveckling från min sida?
Lite, för SDK-ändringar och allt som körs på dina servrar, och jag tar in en attributionsingenjör från mitt nätverk för att göra det tillsammans med ditt team. Du behöver en utvecklare som kan skicka ändringar under uppdraget. Designen och ägarskapet av lagret ligger kvar hos mig.
Finns det en minimispend?
Retainers är byggda för appar som redan spenderar runt 100 000 $ i månaden eller mer på paid UA, eller är finansierade för att nå dit. Under den nivån är growth audit tillgänglig oavsett spendnivå, och en betald 90-minuterssession täcker diagnosen på egen hand. Väldigt små kampanjer klarar inte Apples sekretesströsklar oavsett hur ren signalen är, och det säger jag på samtalet.
Källor
- App Tracking Transparency Apple Developer Documentation. Kontrollerad 29 september 2026.
- AdAttributionKit Apple Developer Documentation. Kontrollerad 29 september 2026.
- Receiving postbacks in multiple conversion windows Apple Developer Documentation, SKAdNetwork. De tre fönstren samt de grova och fina värdena. Kontrollerad 29 september 2026.
- Receiving postbacks in multiple conversion windows (AdAttributionKit) Apple Developer Documentation. Fönster, slumpmässiga fördröjningar för postbacks, datanivåer för postbacks och landskoden. Kontrollerad 29 september 2026.
- Configuring attribution rules for your app Apple Developer Documentation. Standardfönster och inställbara fönster för klick och visningar. Kontrollerad 29 september 2026.
- App ad attribution overview Apple Ads Help. Apple Ads registrerades med AdAttributionKit den 10 april 2025. Kontrollerad 29 september 2026.
- Acquisition App Store Connect Analytics Help. Källtyper, och hur nedladdningar, försäljning och prenumerationer krediteras dem. Kontrollerad 29 september 2026.
- Metric definitions App Store Connect Analytics Help. Mätvärden för nedladdningar och deras miniminivåer. Kontrollerad 29 september 2026.
- Analytics Reports API App Store Connect Analytics Help. Datans fullständighet och integritetströsklar. Kontrollerad 29 september 2026.
- Conversions API for App Events Meta for Developers. Kontrollerad 29 september 2026.
- Key concepts for Meta's Aggregated Event Measurement and Apple's SKAdNetwork Meta Business Help Center. Kontrollerad 29 september 2026.
- About campaign attribution methods Meta Business Help Center. AEM-attributionsfönster för appmarknadsföringskampanjer på iOS 14 och senare. Kontrollerad 29 september 2026.
- Ads Manager reporting differences between Meta's Aggregated Event Measurement and Apple's SKAdNetwork Meta Business Help Center. Fördröjningar i rapporteringen, och AEM-rapportering skickad till MMP:er från den 9 oktober 2024. Kontrollerad 29 september 2026.
- Troubleshoot issues with app eligibility for Aggregated Event Measurement Meta Business Help Center. Kontrollerad 29 september 2026.
- Set up mobile app conversion tracking Google Ads Help. Kontrollerad 29 september 2026.
- About bidding in App campaigns Google Ads Help. Target ROAS använder conversion values från in-app-events. Kontrollerad 29 september 2026.
- Understanding iOS App campaign measurement and reporting Google Ads Help. Modellerade konverteringar, ICM och SKAdNetwork jämförda. Kontrollerad 29 september 2026.
- About Integrated Conversion Measurement for App Campaigns Google Ads Help. Krav för iOS. Kontrollerad 29 september 2026.
- About on-device conversion measurement for iOS App campaigns Google Ads Help. Krav, och inaktiv för användare i EES, Storbritannien och Schweiz. Kontrollerad 29 september 2026.
- Set up your SKAdNetwork conversion value schema Google Ads Help. Googles modellering använder bara fina värden. Kontrollerad 29 september 2026.
- About App Event Optimization TikTok Ads Manager Help Center, uppdaterad maj 2025. Kontrollerad 29 september 2026.
- Events API TikTok Business Help Center, uppdaterad april 2025. Serverbaserade events över webb, app och offline. Kontrollerad 29 september 2026.
- Google Ads (AdWords): FAQ and discrepancies AppsFlyer Help Center, redigerad 16 mars 2026. Google Ads visar sina egna modellerade installationer, AppsFlyer visar ICM-anspråk. Kontrollerad 29 september 2026.
- Meta Ads Aggregate Event Measurement (AEM) for iOS AppsFlyer Help Center, redigerad 25 maj 2026. IP-adress och IDFV krävs på events från server till server. Kontrollerad 29 september 2026.
- SKAN modeled data AppsFlyer Help Center. Ett MMP som beskriver hur det modellerar de värden Apple håller tillbaka, noggrannheten i den modelleringen är leverantörens eget påstående. Kontrollerad 29 september 2026.
- Meta Ads integration RevenueCat-dokumentation. Konfigurerar varken SKAN eller AEM och uppdaterar inte conversion values i SKAN. Kontrollerad 29 september 2026.
- Singular integration RevenueCat-dokumentation. Serverevents kan inte ändra conversion values i SKAdNetwork. Kontrollerad 29 september 2026.