Meta Attribution Penceresi Daraldı: BigQuery ile Telafi Katmanı Nasıl Kurulur

Meta, 12 Ocak 2026’da Ads Insights API’deki 7d_view ve 28d_view attribution pencerelerini kaldırdı¹. Pencere daraldı; performansta bir değişiklik olmasa bile raporlanan conversion sayıları geri çekildi. Bu düşüş bir kampanya sorunu değil, ölçüm kaybı. CAPI kurulu ajansların çoğu hâlâ bu açığı Meta’nın pixel dashboard’undan okumaya çalışıyor, oysa telafi katmanı BigQuery tarafında.

Bu yazı yeni bir geçiş rehberi değil. Mayıs 2025’te Offline Conversions API kapatıldı², ajansların çoğu bir yıl önce standart CAPI’ye geçti. Bugünkü sorun geçiş değil, geçtikten sonra Meta’nın UI’ının gösterdiği tabloya güvenememek. Burada ele alacağım mimari, 4 katmanlı bir referans yapı: BigQuery Attribution Telafi Katmanı. Signal Recovery, Transport, Extended Look-back ve Reconciliation bileşenleriyle Ads Manager’dan bağımsız, ham veriye dayalı kanal katkı raporu kurulur.

12 Ocak 2026 Sonrası Meta Ölçümü Neden Daraldı

Meta’nın Developer Blog’unda 16 Ekim 2025’te yayımlanan duyuru üç ay önceden haber verdi¹. 12 Ocak 2026’dan itibaren Ads Insights API’nin action_attribution_windows parametresi üzerinden 7d_view ve 28d_view artık dönmüyor. Etkilenen alan ID’leri şunlar:

• actions_7d_view
• action_values_7d_view
• actions_28d_view
• action_values_28d_view

Aynı zamanda tüm kombine pencereler (7d_click + 28d_view, 1d_click + 7d_view, 7d_click + 7d_view ve benzeri) kapandı³. Hâlâ çalışan pencereler: 1d_view, 1d_click, 7d_click, 28d_click, 1d_engaged_view ve advertiser’ın attribution settings default’u. Yeni default çoğu hesapta 7d_click + 1d_view olarak oturdu.

Aynı duyuruda ikinci bir darbe daha var: breakdown sınırlamaları. Unique-count alanlar (unique_actions, cost_per_unique_action_type) ve hourly breakdowns (hourly_stats_aggregated_by_advertiser_time_zone, user_time_zone) için 13 aylık historical limit geldi. Frequency breakdowns 6 ay, MMM breakdowns yalnızca asynchronous job’larla çalışıyor. Total values etkilenmedi ve 37 aya kadar erişilebilir.

Etkinin en yoğun olduğu segmentler net: awareness ve video kampanyaları, uzun satış döngülü B2B, yüksek konsiderasyonlu ecommerce. Sektör raporları farklı aralıklarda rakam veriyor⁴⁵. GA4 tarafında da paralel bir sorun var: direct şişmesi ve attribution model seçimi kampanya kaynağını belirsizleştiriyor, iki cephe birlikte ele alınmadan tablo kapanmıyor.

Bağlam: Mayıs 2025 Offline API sunset

Meta, Offline Conversions API’yi Mayıs 2025’te discontinued olarak işaretledi². Artık tüm offline event’ler standart Conversions API üzerinden, action_source değeriyle physical_store veya system_generated olarak gönderiliyor. Tek bir dataset online ve offline event’leri birleşik taşıyor. Ajansların çoğu o tarihte geçişi tamamladı. Bugün gündemdeki soru artık “CAPI’ye nasıl geçerim” değil, “geçiş bitti, Meta’nın bana gösterdiği rakam daralırken ben kendi kanal katkı raporumu nasıl kurarım”. Bu post, daha önce ele aldığım KPI ölçüm krizi ve privacy-agent-commerce hub’ının Meta tarafındaki uygulama katmanı olarak okunabilir.

BigQuery Attribution Telafi Katmanı: 4 Katman Mimarisi

Attribution Telafi Katmanı dört bileşenden oluşuyor. Her biri bir sonrakinin önkoşulu veya beslemesi. İlk iki katman zorunlu sıra, son iki katman paralel kurulabilir.

#	Katman	Ne yapar	Gerekli altyapı
1	Signal Recovery	Meta’nın gördüğü sinyali temiz ve tam topla	Pixel + CAPI redundant, EMQ 8+, dedup doğru
2	Transport	BQ’dan CAPI’ye production pipeline	Dataflow veya Workflows + validation + retry
3	Extended Look-back	BQ’da 28+ gün custom attribution	GA4 BQ export + CAPI event log + SQL MTA
4	Reconciliation	Ads Manager ile BQ arasındaki fark raporu	Daily diff query + dashboard + alert

Bir solo operatör ya da küçük ekip ilk iki katmanı üç hafta içinde kurabilir. Extended Look-back ve Reconciliation ajans deliverable’ı olarak hafta hafta büyütülebilir. Enterprise tarafta dört katmanın da ayrı sahipleri olur, Reconciliation çoğu zaman veri ekibi + finans kesişiminde.

Katman 1: Signal Recovery ile CAPI Event Kalitesi

Meta’nın gördüğü tüm conversion sinyali bu katmandan akar. Burada bir eksik, sonraki üç katmanı temelsiz bırakır.

Redundant events: Pixel ve CAPI birlikte

Meta’nın Best Practices dokümanı Pixel ve CAPI’nin birlikte, aynı event’i paralel göndermesini öneriyor⁶. Tek başına CAPI, ad delivery optimization’ı zayıflatıyor; tek başına Pixel, iOS ve browser kısıtları altında eksik. Redundant setup’ta event_id + event_name anahtarıyla dedup devreye girer.

Parameter zorunlulukları

Event payload’ında her zaman bulunması gereken alanlar:

• action_source: website, physical_store veya system_generated
• event_source_url: web event’ler için
• client_user_agent: web event’ler için
• event_id: Pixel ile eşleşme anahtarı
• external_id: CRM ya da kullanıcı ID’si (hash’lenmiş), en güçlü identifier’lardan biri

Yanlış action_source event reject riski yaratır. Fiziksel mağaza satışı physical_store, CRM tetikli olay (qualified lead, closed-won) system_generated, web website. Bu ayrımı pipeline’da netleştirmezsen Meta event’i beklediği attribution modeline sokamaz.

Hash kuralları

SHA-256 ile hash’lenecek alanlar: em, ph, gen, db, ln, fn, ct, st, zip, country. Hash öncesi standartlaştırma: lowercase ve trim whitespace. Phone numarası E.164 formatında + prefix olmadan gönderilir (Google Ads’tekinden farklı bir kural). Hash edilmeyen alanlar: madid, lead_id, fbp, fbc.

import hashlib
import re

def normalize_and_hash_email(email: str) -> str:
    if not email:
        return ""
    normalized = email.strip().lower()
    return hashlib.sha256(normalized.encode("utf-8")).hexdigest()

def normalize_and_hash_phone(phone: str) -> str:
    if not phone:
        return ""
    digits_only = re.sub(r"\D", "", phone)
    if digits_only.startswith("90") and len(digits_only) == 12:
        normalized = digits_only
    elif digits_only.startswith("0") and len(digits_only) == 11:
        normalized = "90" + digits_only[1:]
    else:
        normalized = digits_only
    return hashlib.sha256(normalized.encode("utf-8")).hexdigest()

Graph API v13’ten itibaren zayıf customer info kombinasyonları (örneğin sadece ct+country+st+zp+ge+client_user_agent) reddediliyor⁶. En az bir güçlü identifier (email, phone veya external_id) her payload’da olmalı.

İki ayrı dedup mekanizması

Burası sık karıştırılıyor. Online ve offline event dedup’u farklı anahtarlarla çalışır:

• Pixel + CAPI (online) dedup: Anahtar event_id + event_name. Pencere 48 saat. user_data (email, phone, fbp, fbc) dedup anahtarı değil, yalnızca identity matching için kullanılır. Event order kritik: browser önce, server sonra gelmeli, aksi halde duplicate count riski.
• Offline-to-offline dedup: Anahtar dataset_id + event_time + event_name + item_number ve order_id varsa (yoksa customer info parameters ile user-based fallback). Pencere 7 gün⁷.

BQ tarafında event’i yazarken order_id sipariş receipt ID’si olarak kurulur, multi-item siparişlerde item_number ile satır bazında ayrılır. Refund, partial refund, aynı order_id ile revize event ve abonelik renewal’ı için özel handling gerekir.

Events Manager’ın Deduplication tab’ında Meta %70 üzeri match oranı bekliyor⁸. Bu eşiğin altındaysan deduplication key’lerinin her source’ta doğru kullanıldığından emin olmak ilk adım.

EMQ hedefleri ve marjinal etki

Event Match Quality 1-10 arası bir skor ve Meta’nın attribution ağırlığını doğrudan etkiliyor⁹:

Event	Hedef EMQ	En yüksek marjinal etki
Purchase	8.8 - 9.3	Hashed email (+4), phone (+3)
AddToCart	8.0+	Email + external_id
Lead	7.5+	Email + phone + fbc
PageView	6.5 - 7.5	fbp + client_user_agent

6 altı EMQ Meta’nın modeline “zayıf sinyal” olarak gider, attribution ağırlığı düşer. Purchase event’lerinde hashed email ve phone en yüksek marjinal etkiye sahip.

Katman 2: Transport ile BigQuery’den CAPI’ye Production Pipeline

Signal Recovery katmanının payload şartlarını karşılayan event’leri güvenilir şekilde Meta’ya taşıyan katman bu. Server-side event işleme yaklaşımının genel çerçevesini etkinlik verilerinin takibinde farklı yaklaşımlar yazısında ele almıştım; bu bölüm aynı çerçevenin BigQuery + CAPI çıkışını somutlaştırıyor. Endpoint:

POST https://graph.facebook.com/{API_VERSION}/{DATASET_ID}/events

Batch riski

CAPI batch başına maksimum 1000 event kabul ediyor ve batch içindeki tek bir invalid event tüm batch’i reddediyor¹⁰. Bu üretim tarafında en kritik tasarım kararlarından biri. Üç katman zorunlu:

1. Pre-flight validation layer: batch’e girmeden önce her event’i required params kontrolünden geçir (action_source, event_time, event_name, en az bir güçlü identifier)
2. Invalid event ayrım tablosu: validation’dan geçemeyen event’ler ayrı bir BQ tablosuna yazılır, root cause ile etiketlenir
3. Retry queue: rate limit veya transient hata alan batch’ler exponential backoff ile yeniden denenir

Transport seçenekleri

Üç yol var:

• Meta Dataflow template (fbsamples/gcp-to-conversions-api-dataflow-template): Meta’nın resmi GCP > CAPI pipeline’ı¹¹. Dataflow’un yönetim yükünü göze alan ekipler için uygun.
• Cloud Workflows + Cloud Scheduler: solo operatör için en düşük maliyet. BQ’dan scheduled query ile event topla, Workflows içinde validate ve batch oluştur, CAPI’ye POST at.
• Reverse ETL (Hightouch, Census): BQ’dan Meta’ya model-based senkron. Data team’in zaten reverse ETL aracı varsa bağlantı en hızlısı.

Minimum BQ schema

Kolon	Tip	Açıklama
event_id	STRING	Pixel ile dedup anahtarı
event_time	INT64 (unix)	Epoch saniye
event_name	STRING	Purchase, Lead, AddToCart vb.
action_source	STRING	website / physical_store / system_generated
order_id	STRING	Offline dedup için
item_number	STRING	Multi-item siparişte satır anahtarı
value	NUMERIC	Conversion değeri
currency	STRING	ISO 4217
user_data	JSON/STRING	Hashed em, ph, external_id vb.
custom_data	JSON	contents[], content_type vb.

Access token ve rate limit

System User token kullan, server-to-server renewable. .env ya da secrets manager’da sakla, minimum yetkiyle scope’la. CAPI’nin kendine özel rate limit’i yok, Marketing API kotası geçerli; Graph API throttle’dan muaf¹⁰. Exponential backoff zorunlu, rate limit yemişken anında retry yapma.

Business SDK (PHP, Node, Java, Python, Ruby) SHA-256 hashing’i otomatik yapıyor. Manuel pipeline yazıyorsan hash ve normalize katmanını sen kur.

Katman 3: Extended Look-back ile BigQuery’de Kendi Attribution Penceren

Meta 7-day click + 1-day view veriyor; BigQuery’de 28+ gün tutabilir, istediğin modeli uygulayabilirsin. Bu katmanın değeri iki yönlü: hem uzun satış döngülü kampanyalarda sinyali kaybetmemek hem de attribution varsayımlarını Meta’nın kara kutusundan çıkarıp kendi mantığına almak.

GA4 BQ export ile CAPI log join

GA4 BigQuery export’u session bazlı değil event bazlı veri akıtıyor¹². CAPI event log tablosu da aynı dataset’te. GA4 + Umami çift kaynaklı bir attribution analiz örneğini BigQuery attribution analizi yazısında adım adım gösterdim; buradaki join mantığı aynı, fark CAPI event log’unun üçüncü kaynak olarak katılması. fbclid veya fbc parametresi üzerinden join kurulur: kullanıcı Meta reklamını tıklayınca landing page’de fbclid cookie’ye yazılır, conversion event’ine fbc olarak taşınır, CAPI payload’unda da aynı değer olur.

WITH touchpoints AS (
  SELECT
    user_pseudo_id,
    event_timestamp,
    traffic_source.source AS channel_source,
    traffic_source.medium AS channel_medium,
    (SELECT value.string_value FROM UNNEST(event_params)
      WHERE key = 'fbclid') AS fbclid
  FROM `project.analytics_123.events_*`
  WHERE _TABLE_SUFFIX BETWEEN
    FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 45 DAY))
    AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
),
purchases AS (
  SELECT
    user_pseudo_id,
    event_timestamp AS purchase_ts,
    ecommerce.purchase_revenue AS revenue
  FROM `project.analytics_123.events_*`
  WHERE event_name = 'purchase'
    AND _TABLE_SUFFIX BETWEEN
      FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 45 DAY))
      AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
)
SELECT
  p.user_pseudo_id,
  p.purchase_ts,
  p.revenue,
  ARRAY_AGG(STRUCT(t.channel_source, t.channel_medium, t.event_timestamp)
    ORDER BY t.event_timestamp) AS touchpoint_path
FROM purchases p
JOIN touchpoints t
  ON p.user_pseudo_id = t.user_pseudo_id
  AND t.event_timestamp <= p.purchase_ts
  AND t.event_timestamp >= p.purchase_ts - (45 * 24 * 60 * 60 * 1000000)
GROUP BY 1, 2, 3;

Bu query 45 günlük look-back penceresinde her conversion için touchpoint path oluşturuyor. LAG() ve LEAD() window fonksiyonları ile first-touch, last-non-direct, time-decay ve position-based modelleri SQL katmanında kurulur. Markov-lite modeli için transition matrix’i geçmiş conversion’lardan öğrenen bir materialized view üzerine inşa edilir.

Kampanya tipine göre look-back

• Direct response ecommerce: 28 gün yeter, iade penceresi sonrasına gerek yok
• Yüksek konsiderasyon ecommerce (mobilya, premium SaaS deneme): 45 gün
• B2B uzun döngü: 90 gün minimum, satış sürecine göre 120’ye kadar

Retention argümanı

12 Ocak 2026’dan itibaren Meta unique-count alanları ve hourly breakdowns için 13 aylık historical limit uyguluyor¹. Yani Meta’nın kendisi eski verini belli bir süre sonra silecek. BQ export sadece attribution için değil, geçmiş verini Meta silmeden önce kendi warehouse’una almak için de zorunlu. Dataslayer’ın önerdiği baseline normalizasyon (Kasım-Aralık 2024 için 1-day view / 7-day view oranı)⁵ BQ’da kalıcı referans tablosu olarak saklanır, tarihsel trend karşılaştırmasında kullanılır.

Supermetrics dokümantasyonu da bir uyarı veriyor³: BQ veya Snowflake destination’ında affected field’ı custom table’dan çıkarırsan destination history erozyona uğrar. Eski snapshot’ı korumak için separate table + migration SQL zorunlu.

arXiv 2025 MTA uyarısı

Multi-touch attribution’ın kendi sınırları var. Amazon’un 2025’te yayımladığı bir çalışma MTA modellerinin gerçek kanal katkısına göre %488 ile %948 arasında hata üretebildiğini gösteriyor¹³. BQ’da kurduğun MTA katmanı Ads Manager’dan daha esnek bir araç, ama hakikat iddiası değil. Incrementality testing ve pazarlama karması modellemesi (MMM) ile birlikte yorumlanır.

Katman 4: Attribution Reconciliation ile Ads Manager vs BQ Fark Raporu

Ajans müşterisinin ya da CFO’nun gördüğü Meta rakamı ile senin BQ’da kurduğun kanal katkı raporu arasındaki boşluğu görünür yapmak bu katmanın işi.

Günlük fark raporu

Ads Manager reported purchases ve BQ custom-attributed purchases aynı BQ dataset’inde birleştirilir. Google Ads Data Transfer BQ dataset’i varsa Google tarafı da aynı shape’te import edilir.

WITH meta_reported AS (
  SELECT
    date,
    SUM(purchases) AS reported_purchases,
    SUM(purchase_value) AS reported_value
  FROM `project.meta_ads.daily_campaign_insights`
  WHERE date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  GROUP BY date
),
bq_attributed AS (
  SELECT
    DATE(purchase_ts) AS date,
    COUNT(*) AS attributed_purchases,
    SUM(revenue) AS attributed_value
  FROM `project.attribution.meta_attributed_purchases`
  WHERE purchase_ts >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  GROUP BY date
)
SELECT
  m.date,
  m.reported_purchases,
  b.attributed_purchases,
  (b.attributed_purchases - m.reported_purchases) AS delta_purchases,
  SAFE_DIVIDE(b.attributed_purchases - m.reported_purchases, m.reported_purchases) AS delta_pct
FROM meta_reported m
FULL OUTER JOIN bq_attributed b USING (date)
ORDER BY date DESC;

Reconciliation kategorileri

• Meta reported + BQ attributed: iyi durumdaki conversion’lar, tutarlı sinyal
• Meta reported + BQ unattributed: Meta’nın ekstra kredi verdiği conversion’lar, olası modelleme fazlalığı
• Meta unreported + BQ attributed: penceresi dolduğu için Meta’nın göremediği, senin topladığın katkı

Dashboard ve alert eşikleri

Günlük fark %15’in üzerine çıkıyorsa bir tarafın sorunlu olduğunu varsay ve araştır. EMQ drop, baseline matching reject, campaign reporting lag, BQ export gecikmesi en sık nedenler. “Attribution delta” metriği ajans deliverable’ı olarak raporlanır, müşteriye Meta dashboard’ının neyi gösteremediğini somut rakamla anlatır.

Dinmo’nun Diptyque vakasında CAPI ve dataset tarafında reconciliation sonrası reported purchase’larda önemli bir geri kazanım görülmüş¹⁴. Bu tip vakalar reconciliation katmanının gerekçesini somutlaştırıyor.

Post-Migration Audit ve Jon Loomer %70 Drop Riski

Mayıs 2025 Offline API sunset’inden bu yana bir yıl geçti. Soru artık “geçtin mi” değil, “geçişin doğru çalışıyor mu”. Aşağıdaki audit checklist bir ajans müşterisinin mevcut kurulumunu değerlendirmek için yeterli.

Audit checklist

• Auto-Tracking açık mı? Events Manager > Data Sets > Settings > Auto Tracking. Offline events’in ad campaigns’e bağlanması için zorunlu. Legacy kampanyalar aktivasyon sonrası yeniden oluşturulmalı olabilir.
• Extend attribution uploads (90d) ve Allow historical conversion uploads ikisi de açık mı? Uzun satış döngüsü için gerekli.
• EMQ trend: son 30 günde Purchase 8.8’in altına düştü mü?
• Dedup rate: Events Manager > Deduplication tab’de %70’in üzerinde mi?
• Batch rejection rate: capi_events_failed tablosunda son 7 günün logları var mı, error code’lar sınıflandırılmış mı?
• Offline Data Quality kolonu düştü mü? Bu EMQ’dan ayrı bir metrik, karıştırma.
• Event freshness tab: event_time ile send time arasındaki gecikme real-time veya 1 saat altında mı?

Jon Loomer vakası

Jon Loomer’ın 2024’teki raporunda geçiş yapan bir reklamverende event accept oranı %70 düştü, “hiçbir şey değiştirmedik” iddiasına rağmen¹⁵. Olası nedenler: action_source yanlış kullanımı, event_id mapping hatası, baseline matching reject, EMQ düşüşü. Mitigation yaklaşımı standart: test events ile paralel çalıştırma süresi, rollback planı, monitoring eşikleri.

Meta resmi dokümantasyonu Offline API için spesifik sunset tarihi vermiyor (yalnızca “legacy” etiketi ve Graph API v17 referansı). “14 Mayıs 2025” tarihi endüstri raporlarından doğrulanıyor², birincil kaynak değil.

TR Ecommerce ve CRM Edge Cases

Türkiye tarafında platforma özgü birkaç tuzak var.

T-Soft, Ideasoft, Ticimax offline alanları

SMS onayı, havale ve kapıda ödeme siparişlerinde event_time siparişin oluşturulduğu değil, siparişin onaylandığı/tahsil edildiği an olarak set edilir. Aksi halde henüz gerçekleşmemiş bir tahsilat Meta’ya Purchase olarak gidiyor, iade ya da iptal olduğunda dedup penceresi yetmiyor. CRM tarafında sipariş status değişikliği webhook’una bağlanmalı.

Telefon normalizasyonu

Türkiye numaralarında +90 prefix strip edilir, E.164 formatında prefix’siz gönderilir (örneğin 90555...). Veritabanında 0555 ile tutulan numaralar için önce leading 0 strip + 90 prepend, sonra hash.

İade penceresi ve dedup çakışması

TR tüketici yasası 14 günlük iade hakkı tanıyor. CAPI offline dedup penceresi ise 7 gün. 8-14. gün arasında gelen iade için ayrı bir reversal event mekanizması kurmazsan Meta’da Purchase sayılı kalır, ROAS yalan söyler. event_name olarak özel bir PurchaseReversal custom event ve negatif value ile pipeline kurulabilir, ama bu custom attribution tarafında ayrıca modellenmeli.

CRM entegrasyonu: fbclid landing’de yakala

HubSpot native Meta CAPI integration’ı ile doğrudan çalışıyor. Salesforce için Datahash, Stape ya da webhook tabanlı çözümler. Hangisi olursa olsun kritik adım aynı: fbclid değeri landing page’de yakalanmalı, contact kaydında first-party cookie veya custom field olarak saklanmalı. Aksi halde CRM event’i (qualified lead, closed-won) attribution’a bağlanamıyor, çünkü fbc parametresi oluşturulamıyor.

B2B uzun döngülü satışta 2-4 hafta arası bir cycle normal. Extended Look-back katmanı olmadan bu event’lerin Meta tarafında görünmesi imkânsıza yakın.

Sonuç

12 Ocak 2026’dan sonra Meta’nın Ads Insights API’de gösterdiği tablo daha dar bir pencere. Bu, reklamlarının kötü performans gösterdiği anlamına gelmiyor; sadece Meta’nın sana gösterdiği tarafın küçüldüğü anlamına geliyor. BigQuery Attribution Telafi Katmanı, Signal Recovery’den başlayıp Reconciliation’a kadar dört katmanlı bir yapıyla Ads Manager’dan bağımsız, ham veriye dayalı bir kanal katkı raporu kurmanın yolu.

Bir ajansın CFO ya da müşteri tarafına verebileceği en somut deliverable “Attribution delta” raporu: Meta ne söylüyor, biz ne görüyoruz, fark nereden kaynaklanıyor. Bu rapor hem Meta platform değişikliklerine karşı dayanıklılık kazandırır hem de gerçek kanal katkı tartışmasını veriye dayalı bir zemine taşır.

Footnotes

1. Ads Insights API Metric Availability Updates (Meta Developers Blog, 16 Ekim 2025) ve Marketing API Changelog. 12 Ocak 2026’dan itibaren 7d_view ve 28d_view Ads Insights API’den kaldırıldı, unique-count ve hourly breakdowns için 13 ay limit, frequency için 6 ay, MMM için asynchronous job zorunluluğu. ↩ ↩² ↩³
2. About the Offline Conversions API (Meta Business Help) — “discontinued in May 2025”. Spesifik tarih iddiası (14 Mayıs 2025) için seresa.io. ↩ ↩² ↩³
3. Facebook Ads: New historical limitations, attribution window and metric removals (Supermetrics Docs) — deprecated field ID listesi ve destination history erozyonu uyarısı. ↩ ↩²
4. Meta Ads Attribution 2026 Changes and Fixes (dojoai.com) — sektör perspektifinden reported conversion drop aralığı tahminleri, iOS 14.5 > 18 > 26 timeline. ↩
5. Meta Ads Attribution Window Removed January 2026 (Dataslayer, Julia Moreno) — sektör aralığı tahminleri, 15 Ocak 2026 targeting consolidation dalgası, baseline normalizasyon metodu. ↩ ↩² ↩³
6. Conversions API Best Practices (Meta Developers) — redundant events, baseline matching requirements, fbp/fbc refresh kuralları. ↩ ↩²
7. Sending Offline Events Using the Conversions API (Meta Developers) — offline dedup mekanizması, customer info parameters, 7/62 gün pencere detayları. ↩
8. Facebook Offline Conversion Tracking Guide 2025 (conversiontracking.io) — Auto-Tracking zorunluluğu, Test Events offline gotcha’sı, E.164 prefix’siz format kuralı. ↩ ↩²
9. Meta API Configuration Best Practices (adamigo.ai) — EMQ hedefleri (Purchase 8.8-9.3, AddToCart 8.0+) ve marjinal etki hesapları. ↩
10. Using the Conversions API (Meta Developers) — batch 1000 event limiti, invalid batch reject davranışı, rate limiting. ↩ ↩²
11. fbsamples/gcp-to-conversions-api-dataflow-template — Meta’nın resmi GCP > CAPI Dataflow template’i. ↩
12. GA4 BigQuery export şeması ve event-level model için Google Analytics BigQuery export schema. ↩
13. “Multi-touch attribution: a comparison” (Amazon, arXiv 2025) — MTA modellerinin incrementality ile karşılaştırmasında %488-948 arası hata rangi. ↩
14. Meta Conversions API 2026 Guide (dinmo.com) — Diptyque vakası ve composable CDP yaklaşımı. ↩
15. Offline Conversions API Deprecation Delayed (Jon Loomer) — ertelenme geçmişi ve %70 event drop vakası. ↩

Önemli Noktalar

• 01 12 Ocak 2026 attribution window deprecation: 7-day view ve 28-day view Ads Insights API'den kaldırıldı, reported conversion drop ortaya çıktı
• 02 BigQuery Attribution Telafi Katmanı 4 bileşen: Signal Recovery, Transport, Extended Look-back, Attribution Reconciliation
• 03 Pixel+CAPI (online) dedup ile offline-to-offline dedup iki ayrı mekanizma: anahtarları ve pencereleri farklı, karıştırılmamalı
• 04 Batch 1000 event max + tek invalid event tüm batch'i reddeder: pre-flight validation layer zorunlu
• 05 EMQ Purchase 8.8-9.3 / AddToCart 8.0+ hedef; hashed email ve phone en yüksek marjinal etkiye sahip

Sık Sorulan Sorular (FAQ)

+ 12 Ocak 2026'da Meta attribution tarafında ne değişti?

Meta, Ads Insights API'de 7-day view ve 28-day view pencerelerini kaldırdı. Hâlâ çalışan pencereler: 1-day view, 1-day click, 7-day click, 28-day click, 1-day engaged view. Yeni default 7-day click + 1-day view. Uzun satış döngülü B2B ve yüksek konsiderasyonlu ecommerce için reported conversion drop ortaya çıkıyor; kayıp performans değil, ölçüm.

+ BigQuery Attribution Telafi Katmanı nedir?

Meta'nın UI'ından bağımsız olarak ham CAPI event'lerini BigQuery'de tutup genişletilmiş look-back penceresi ve custom multi-touch attribution SQL ile gerçek kanal katkısını raporlayan referans mimari. 4 katman: Signal Recovery, Transport, Extended Look-back, Attribution Reconciliation.

+ Offline events'ta dedup nasıl çalışır?

Offline events yalnızca diğer offline events'e karşı deduplike edilir. Varsayılan order_id bazlı, yoksa customer info parameters ile user-based. Anahtar kombinasyon dataset_id + event_time + event_name + item_number. Maksimum dedup penceresi 7 gün. Bu mekanizma, Pixel+CAPI event_id dedup'undan tamamen ayrıdır.

+ Event Match Quality (EMQ) skorumu nasıl yükseltirim?

Her event'e hashed email ve phone, external_id, fbp ve fbc parametrelerini dahil ederek. Purchase için 8.8-9.3, AddToCart için 8.0+ hedef. 6 altı EMQ Meta'nın attribution'ında ağırlık kaybı yaratır. En yüksek marjinal etki: hashed email ve phone.

+ BigQuery batch upload'da en büyük risk nedir?

Meta CAPI batch başına maksimum 1000 event kabul eder ve batch içindeki tek bir invalid event tüm batch'i reddeder. Dataflow veya Cloud Workflows tasarımında pre-flight validation, invalid event'leri ayıran tablo ve retry queue zorunludur.

+ Test Events tool offline conversion'lar için çalışır mı?

Hayır. Test Events tool yalnızca web events için çalışıyor. Offline event testi için unique bir değer (örneğin saat damgası) ile gerçek event gönderilir, Dataset Overview'da kabul beklenir, sonra ads dashboard'a yansıması doğrulanır.