Facebook-händelser syns inte i Events Manager (Flutter)

Innan du ändrar någon kod: uteslut rapporteringskedjan. Metas aggregerade rapportering i Events Manager sker inte i realtid. En händelse som din app skickade korrekt kan saknas i den vy du tittar på helt enkelt för att den ännu inte har bearbetats in i den.

Felsök därför inte mot den aggregerade instrumentpanelen. Använd Test Events i Events Manager i stället: öppna din app i Events Manager, gå till fliken Test Events och utlös sedan händelsen manuellt på en enhet. Test Events visar händelser inom sekunder, vilket förvandlar frågan om händelsen kom fram till ett ja eller ett nej.

Två utfall, och de leder dig till olika halvor av den här sidan. Syns händelsen i Test Events fungerar leveransen och ditt problem är attribution: hoppa till sista avsnittet. Syns ingenting efter en manuellt utlöst händelse når händelsen inte fram till Meta, och konfigurationsavsnitten nedan är där du börjar.

En detalj medan du testar. SDK:t lagrar händelser och skickar dem i buntar, så anropa flush() efter händelsen du testar: det skickar allt som ligger lagrat till servern direkt, vilket tar bort ytterligare en anledning till att en händelse dröjer.

Tre lager, i den här ordningen. Varje lager kan ge symptomet på egen hand, och varje lager är billigare att utesluta än det som följer.

1. Konfiguration. App-id, client token och de poster i manifestet eller plist-filen som pekar SDK:t mot dem. Är de fel skickas ingenting alls.
2. Transport. Graph API-version, värdetyper i händelseparametrar och de inställningar som undertrycker sändning. Händelserna skapas i din kod och accepteras aldrig av Meta.
3. Attribution. Händelserna kommer fram och registreras, men siffrorna som kopplas till dina kampanjer stämmer inte med dina egna data.

Ordningen spelar roll eftersom attributionsproblem utifrån ser exakt ut som leveransproblem. Båda visar sig som ett antal som är för lågt, eller noll. De flesta börjar felsöka i det lager de skrev själva, vilket oftast är lagret där ingenting är trasigt, och förlorar en dag där. Fastställ att händelserna kommer fram innan du diskuterar vad siffrorna betyder.

Två saker måste vara på plats. Att ha den ena utan den andra är den vanligaste Android-orsaken till att ingenting kommer fram.

Strängresurserna

I android/app/src/main/res/values/strings.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>
  <string name="facebook_app_id">[APP_ID]</string>
  <string name="facebook_client_token">[CLIENT_TOKEN]</string>
  <string name="fb_login_protocol_scheme">fb[APP_ID]</string>
  <string name="app_name">[APP_NAME]</string>
</resources>

Referenserna i manifestet

Strängresurserna räcker inte i sig. Posterna meta-data i AndroidManifest.xml är vad SDK:t faktiskt läser vid start. Utan dem ligger värdena kvar i dina resurser och ingenting slår någonsin upp dem.

<application android:label="@string/app_name" ...>
  <meta-data android:name="com.facebook.sdk.ApplicationId" android:value="@string/facebook_app_id"/>
  <meta-data android:name="com.facebook.sdk.ClientToken" android:value="@string/facebook_client_token"/>
</application>

Byggvarianter

Har din app byggvarianter (build flavors), kontrollera vilken strings.xml du redigerade. En variants resurskatalog skriver över den gemensamma, så värden som placerats i fel variants strings.xml finns helt enkelt inte i det bygge du kör. Det är en vanlig orsak och den gömmer sig väl: filen du har öppen på skärmen ser korrekt ut.

Bygg den variant du testar och kontrollera det sammanslagna manifestet och de sammanslagna resurserna som bygget producerar, inte källfilerna du redigerade.

Alla tre nycklarna hör hemma i Info.plist:

<key>FacebookAppID</key>
<string>[APP_ID]</string>
<key>FacebookClientToken</key>
<string>[CLIENT_TOKEN]</string>
<key>FacebookDisplayName</key>
<string>[APP_NAME]</string>

En saknad eller felaktig FacebookClientToken är en av de vanligaste orsakerna till att händelser tyst inte kommer fram. Appen byggs. SDK:t initieras. Dina anrop till logEvent returnerar utan fel. Ingenting når Events Manager, och ingenting i appen berättar varför.

Hämta värdet i App Dashboard under Settings > Advanced > Security > Client token och jämför det tecken för tecken med det som står i Info.plist. En client token kopierad från en annan app i samma företagskonto ser fullt rimlig ut och fungerar inte.

Facebook SDK v18.x levereras med en standardversion av Graph API som Meta redan har tagit bort från produktion. Standardvärdet skiljer sig mellan plattformarna.

Varför det spelar roll att låsa en version

En borttagen version är inget stup. Metas versionsguide säger att när en version inte längre går att använda sätts anrop mot den till den äldsta nästa version som fortfarande går att använda. Anropen besvaras alltså, men av den version Meta dirigerar dem till och inte den din app bad om. Har du låst en version medvetet är det precis det läget du ville undvika.

Det som faktiskt landar hos dig är meddelandet. En app på ett gammalt standardvärde får ett avvecklingsmejl från Meta med en deadline för borttagning, och den deadlinen kommer från Metas aktuella golv för utvecklarnotiser, inte från det ursprungliga utgångsdatumet för den version du råkar köra. Ett sådant rapporterades på det här pluginet som ärende #474:

Your app is currently accessing a version of the Marketing API prior to v23.0. On February 19, 2026, all versions prior to v23.0 will be removed.

Golvet flyttas enligt Metas eget schema, så versionen och datumet i det meddelande du får blir inte de här. Formen är poängen: en deadline du inte har valt, på en version du inte medvetet har valt.

Vad pluginet gör åt det

facebook_app_events skriver över Graph API-versionen vid initieringen av pluginet, så de flesta appar behöver ingen konfiguration för det alls. I plugin 0.30.3 är den låsta versionen v24.0. Betrakta pluginets README och CHANGELOG som källan till det aktuella värdet, eftersom det flyttas när Metas stödda intervall flyttas.

Behöver du en specifik version, till exempel för att matcha din backend, anropa setGraphApiVersion så tidigt som möjligt vid appstart, innan något som kan utlösa ett Graph API-anrop. Ditt anrop vinner: pluginet sätter sitt standardvärde när det kopplas in, och ditt Dart-anrop körs efter det.

final facebookAppEvents = FacebookAppEvents();

// Optional. The plugin already sets a default at initialization.
await facebookAppEvents.setGraphApiVersion('v24.0');

await facebookAppEvents.activateApp();

Två fall ligger kvar på SDK:ns standardvärde. En app som använder det nativa SDK:t direkt, utan det här pluginet i initieringsvägen, får den version som SDK:t levererar i stället för en aktuell. Samma gäller en fork där överskrivningen har tagits bort.

Meta har inte åtgärdat det. När SDK v19 släpps med ett korrigerat standardvärde blir överskrivningen verkningslös och anropet ovan kan tas bort ur din kod.

De nativa Facebook-SDK:erna accepterar bara String och numeriska värden i händelseparametrar. En händelse som bär ett värde av någon annan typ kastas bort av SDK:t: tyst, utan fel, och den syns inte någonstans i Events Manager. Inte bara den felaktiga parametern. Hela händelsen.

facebook_app_events gör den tystnaden synlig. logEvent tar emot String, num och bool. Booleaner konverteras till "1" och "0", enligt Metas konvention för ja och nej, så att händelsen registreras identiskt på båda plattformarna. Alla andra typer som inte är null ger ett ArgumentError på anropsstället i stället för att försvinna.

Strukturerade värden måste kodas som en JSON-sträng först, vilket är vad Meta föreskriver för parametrar som fb_content:

// Throws ArgumentError: a List is not an accepted parameter value type.
await facebookAppEvents.logEvent(
  name: 'checkout_started',
  parameters: {'fb_content': items},
);

// Correct: encode the structure as a JSON string first.
await facebookAppEvents.logEvent(
  name: 'checkout_started',
  parameters: {'fb_content': jsonEncode(items)},
);

Det här avsnittet finns eftersom en tyst bortkastad händelse är precis det symptom som får folk att hamna här. Anropar du det nativa SDK:t direkt någonstans i appen, eller loggar du händelser genom ett annat omslag, kontrollera värdetyperna där. Ett ArgumentError från det här pluginet är goda nyheter i jämförelse: det talar om vilken parameter som är fel.

Det här pluginet implementerar inte ATT-dialogen, hanterar inte samtycke och gör inte att din app uppfyller integritetskraven. Det ansvaret ligger på din app, och inget plugin kan ta över det.

Vad pluginet gör är att exponera det nativa SDK:ts egna integritetsinställningar. Att sätta dem rätt är också din apps uppgift, och sätter du en av dem fel får du uteblivna data utan något felmeddelande.

setAdvertiserIdCollectionEnabled(bool)

Mappar 1:1 mot den nativa inställningen på båda plattformarna: Settings.shared.isAdvertiserIDCollectionEnabled på iOS och FacebookSdk.setAdvertiserIDCollectionEnabled på Android. Den styr om annonsörs-id:t, IDFA på iOS eller Google Advertising ID på Android, skickas med dina händelser. På iOS är annonsörs-id:t bara tillgängligt när ATT-tillstånd har beviljats, så att sätta detta till true ger inte i sig någon identifierare.

setAdvertiserTracking är avvecklad och gör ingenting på iOS 17+

Anropar din app den fortfarande och förväntar sig en effekt har du en tyst bugg. Settings.isAdvertiserTrackingEnabled avvecklades i Facebook SDK v17. SDK:t härleder nu spårningssamtycke från ATTrackingManager.trackingAuthorizationStatus och ignorerar sättaren på iOS 17+. På Android finns ingen flagga för spårning alls, så anropet reduceras till setAdvertiserIdCollectionEnabled(enabled && collectId). Använd setAdvertiserIdCollectionEnabled i stället, och begär ATT-tillstånd i din app.

Två fler vägar som undertrycker data

setDataProcessingOptions och setLimitEventAndDataUsage begränsar båda vad Meta får göra med det du skickar: Limited Data Use i det första fallet, och i det andra all användning utöver analys och konverteringar. Vilken som helst av dem, satt någonstans vid appstart, kan förklara rapportering du uppfattar som utebliven. Sök efter båda, även inne i en samtyckes-SDK som du inte har skrivit själv.

Vad det gör med dina siffror

Om ATT-dialogen inte har besvarats, eller om din samtyckesgrind förhindrar initieringen, flödar inga händelser. Gapet i Events Manager är identiskt med det gap en trasig integration ger. Därför ligger det här avsnittet mellan konfiguration och attribution: det är lagret där appen är korrekt, pluginet är korrekt, och data ändå inte finns där.

Om Test Events visar din händelse, konfigurationen ovan stämmer, och kampanjsiffrorna ändå avviker från din egen databas, har du inget leveransproblem. Du har ett attributionsproblem, och det är en annan utredning med andra verktyg.

De vanliga orsakerna:

• SKAdNetwork: konverteringsfönster och värdemappning. Vid SKAdNetwork-attribution på iOS tar Meta emot en postback enligt Apples schema, som bär det konverteringsvärde du har konfigurerat och inte händelsen så som du loggade den. Om den mappningen inte representerar vad du vill att kampanjen ska lära av, lär kampanjen av fel signal, och totalerna kommer inte att stämma rad för rad med din databas.
• Conversions API: serverhändelser som överlappar klienthändelser. När samma köp skickas både från appen och från din server utan en gemensam nyckel för deduplicering har Meta inget tillförlitligt att matcha dem på och kan räkna det två gånger.
• Attributionsfönster. Meta tillskriver en konvertering det klick eller den visning som föregick den inom sitt fönster. Din databas tillskriver den vad din egen modell säger. Två modeller över samma händelser ger två olika tal, och inget av dem är en bugg.

Alla tre går att kontrollera. Ingen av dem går att kontrollera från en webbsida. De kräver det bygge du faktiskt släpper, kontot i Events Manager, annonskontot och dina egna siffror sida vid sida, eftersom svaret oftast ligger i skillnaden mellan dem snarare än i någon av dem för sig.

Det är den ärliga gränsen för en skriven guide. Har du arbetat igenom allt ovan, kommer händelserna fram och går pengarna ändå inte ihop, är det som återstår att någon läser din uppsättning med data framför sig. Alternativen nedan säger vilka av de fallen vi hanterar gratis och vilket vi tar betalt för.