# S2S Postback Nedir? Server to Server Tracking ile Çerezsiz Dönüşüm Takibi

> Postback, bir dönüşüm gerçekleştiğinde reklamverenin sunucusunun bu bilgiyi doğrudan affiliate ağının sunucusuna bildirdiği bir HTTP isteğidir. S2S (server to server) postback, tarayıcı ve çerezden bağımsız çalıştığı için ITP, reklam engelleyiciler ve uygulama içi tarayıcılardan etkilenmez; bu yüzden bugün en güvenilir dönüşüm takip yöntemidir.

Kaynak: https://adfacten.com/blog/s2s-postback-nedir · Yayın: 2026-11-03 · Güncelleme: 2026-11-08 · Yazar: Adfacten Editör Ekibi

## Önemli noktalar

- S2S postback, dönüşümü tarayıcı yerine sunucudan bildirir; çerez silinse ya da piksel engellense bile kayıt kaybolmaz.
- Akışın kalbi click ID'dir: tıklamada üretilir, landing URL'ine eklenir, siparişle saklanır ve postback'te geri gönderilir.
- order_id ile tekilleştirme sayesinde aynı isteği tekrar göndermek güvenlidir; çift sayım oluşmaz.
- Durum güncellemeleri (bekliyor, onay, red, iade) aynı postback'in status parametresiyle yönetilir.
- HMAC imzası, IP izin listesi ve test aracı birlikte kullanıldığında entegrasyon hem güvenli hem doğrulanabilir olur.

Postback nedir sorusunun kısa cevabı şudur: bir kullanıcı satın alma, üyelik ya da başvuru gibi bir hedefi tamamladığında, reklamverenin sunucusunun bu bilgiyi affiliate ağının sunucusuna doğrudan bildirdiği bir HTTP isteğidir. Bu yönteme **S2S postback** (server to server, yani sunucudan sunucuya dönüşüm bildirimi) denir.

Çerezlerin her geçen yıl daha kısa ömürlü hâle geldiği, tarayıcıların takip kodlarını sessizce engellediği bir dönemde, server to server tracking artık "ileri seviye" bir seçenek değil, sağlıklı bir affiliate programının asgari şartıdır. Bu rehberde S2S postback'in nasıl çalıştığını, gerçek bir istek örneğini, tekilleştirme ve güvenlik kurallarını ve entegrasyonu nasıl test edeceğinizi adım adım anlatıyoruz.

Rehber hem teknik ekipler hem de entegrasyonu yöneten pazarlama sorumluları için yazıldı. Affiliate marketing'in temellerine yabancıysanız önce [Affiliate Marketing Nedir?](/blog/affiliate-marketing-nedir) yazısına göz atmanızı öneririz.

## Postback nedir? S2S postback'in tanımı

S2S postback, dönüşüm bilgisinin kullanıcının tarayıcısı yerine reklamverenin sunucusundan affiliate ağının sunucusuna gönderildiği bir dönüşüm takip yöntemidir. Bilginin taşıyıcısı tarayıcı değil, iki sunucu arasındaki doğrudan bir istek olduğu için çerez, JavaScript veya sayfa yüklenmesi gibi kırılgan unsurlara ihtiyaç duymaz.

Klasik takipte zincir şöyledir: kullanıcı tıklar, tarayıcıya bir çerez yazılır, kullanıcı satın aldığında teşekkür sayfasındaki piksel bu çerezi okuyup ağa haber verir. Zincirin her halkası tarayıcıya bağlıdır ve herhangi biri koptuğunda satış "kayıp" olur. Yayıncı komisyonunu alamaz, reklamveren de hangi kanalın gerçekten çalıştığını göremez.

S2S modelinde zincir kısalır. Tıklamada üretilen benzersiz kimlik (**click ID**) landing sayfasının URL'ine eklenir, reklamveren bu değeri siparişle birlikte veritabanına yazar ve sipariş tamamlandığında kendi sunucusundan ağa bildirir. Tarayıcı sadece ilk adımda, click ID'yi taşımak için kullanılır.

Terimler bazen karıştırılır, kısaca netleştirelim:

- **Postback URL:** Dönüşüm bildiriminin gönderildiği adres. Reklamveren için bu, ağın takip sunucusudur.
- **Click ID:** Her tıklamaya özel, ağın ürettiği kimlik. Dönüşümü doğru yayıncıya bağlayan anahtardır.
- **Goal (hedef):** Bildirilen olayın türü; satış, kayıt, kurulum, ilk yatırım gibi.
- **Yayıncı postback'i:** Ağın, dönüşümü yayıncının kendi takip sistemine ilettiği ikinci yöndeki bildirim.

## Piksel ile S2S postback karşılaştırması

Piksel tarayıcıda çalışır ve çerezlere dayanır; S2S postback sunucuda çalışır ve click ID'ye dayanır. İkisi arasındaki fark, özellikle mobil trafiğin ve gizlilik odaklı tarayıcıların yoğun olduğu kampanyalarda dönüşüm sayısına doğrudan yansır.

| Özellik | Piksel (JavaScript / görsel) | S2S postback |
|---|---|---|
| Çalıştığı yer | Kullanıcının tarayıcısı | Reklamverenin sunucusu |
| Atıf anahtarı | Tarayıcı çerezi | Click ID (URL'den saklanır) |
| Reklam engelleyici etkisi | Engellenebilir | Etkilenmez |
| ITP / çerez kısıtlamaları | Etkilenir | Etkilenmez |
| Uygulama içi tarayıcılar | Sıklıkla veri kaybı | Etkilenmez |
| Kurulum zorluğu | Düşük (kod yapıştırma) | Orta (backend geliştirme) |
| Durum güncelleme (onay/red/iade) | Yapılamaz, hep "bekliyor" başlar | `status` parametresiyle yapılır |
| Güvenlik | Herkese açık kimlik, sahteciliğe açık | Gizli token + isteğe bağlı HMAC imzası |
| Gecikmeli dönüşüm (ör. kredi onayı) | Uygun değil | Uygun |
| Mobil uygulama | Uygun değil | MMP üzerinden uygun |

Bu tablo pikselin işe yaramaz olduğu anlamına gelmez. Sunucu tarafı geliştirme kaynağı olmayan küçük bir e-ticaret sitesi için piksel hızlı bir başlangıçtır. En sağlam kurulum ise ikisini birlikte çalıştırmaktır: aynı `order_id` ile hem piksel hem postback gönderildiğinde sistem bunları tekilleştirir ve tek dönüşüm sayar.

> **Adfacten'de:** Pikselden gelen dönüşümler her zaman **bekliyor** durumunda başlar ve pikselde `status` parametresi yok sayılır. Onay, red ve iade yalnızca S2S postback, panel veya API ile yapılır. Gizli postback token'ınız piksel koduna asla yazılmaz; piksel yalnızca herkese açık reklamveren kimliğinizi (`org_…`) kullanır.

## Çerezsiz dünyada server to server tracking neden şart?

Server to server tracking şarttır çünkü tarayıcı tabanlı ölçümün dayandığı üç temel, yani üçüncü taraf çerezler, uzun ömürlü birinci taraf çerezler ve engellenmeyen JavaScript, artık güvenilir değildir. Satışın gerçekleştiği anda bu temellerden biri eksikse piksel hiçbir şey bildirmez.

**ITP ve tarayıcı kısıtlamaları.** Safari'nin Intelligent Tracking Prevention (akıllı takip önleme) özelliği ve benzer mekanizmalar, takip amaçlı görülen çerezlerin ömrünü kısaltır ya da tamamen engeller. Kullanıcı bugün tıklayıp birkaç gün sonra satın aldığında çerez çoktan silinmiş olabilir. Kampanyanızın atıf penceresi 30 gün olsa bile tarayıcı bu süreye uymayabilir.

**Reklam engelleyiciler.** Popüler engelleyici listeleri, bilinen takip alan adlarına giden istekleri doğrudan keser. Teşekkür sayfasındaki piksel hiç çalışmaz; reklamverenin sisteminde sipariş vardır ama ağın sisteminde yoktur.

**Uygulama içi tarayıcılar.** Sosyal medya uygulamalarının içinden açılan linkler, ayrı bir tarayıcı ortamında çalışır. Kullanıcı ürünü orada görüp daha sonra asıl tarayıcısından veya uygulamadan satın aldığında çerez taşınmaz.

**Gecikmeli ve çevrimdışı dönüşümler.** Kredi başvurusunun onaylanması, sigorta poliçesinin kesilmesi veya B2B bir teklifin imzalanması günler sürebilir. Bu anda kullanıcı ortada yoktur; bildirimi yapabilecek tek taraf reklamverenin sunucusudur.

Bu dört durumun ortak sonucu "kayıp satış"tır. Yayıncılar komisyon alamadıkları kampanyalardan çekilir, reklamveren de en verimli kanallarını yanlışlıkla kısar. S2S postback bu sızıntıyı kapatarak programın uzun vadeli sağlığını korur. Yayıncı perspektifinden konuya [Affiliate Marketing ile Para Kazanma](/blog/affiliate-marketing-ile-para-kazanma) rehberinde de değiniyoruz.

## Click ID akışı adım adım nasıl işler?

Click ID akışı, tıklamada üretilen benzersiz kimliğin landing sayfasına taşınması, siparişle saklanması ve dönüşümde ağa geri gönderilmesinden oluşur. Aşağıdaki adımlar Adfacten'deki gerçek akışı yansıtır.

1. **Kullanıcı yayıncının takip linkine tıklar.** Ağ tıklamayı kaydeder, kaynak, ülke, cihaz ve yayıncının eklediği `sub1`–`sub10` alt parametreleriyle birlikte imzalı ve süreli bir click ID üretir.
2. **Kullanıcı landing sayfasına yönlendirilir.** Kampanyanın landing URL'inde `{click_id}` makrosu varsa bu makro gerçek değerle değiştirilir. Örneğin `https://magaza.com/kampanya?cid={click_id}` adresi, kullanıcıya `?cid=...` ile ulaşır. Makro yoksa click ID, `afclk` parametresiyle otomatik eklenir.
3. **Reklamveren click ID'yi saklar.** Landing sayfası `cid` (veya `afclk`) değerini okuyup kullanıcının oturumuna yazar. Kullanıcı sipariş verdiğinde bu değer sipariş kaydına taşınır.
4. **Dönüşüm gerçekleşir.** Ödeme onaylandığında, kayıt tamamlandığında veya hedef olay her neyse gerçekleştiğinde, reklamverenin backend'i postback isteğini hazırlar.
5. **Sunucu ağa postback gönderir.** İstek; postback token'ı, click ID'yi, goal'ü, tutarı, para birimini ve sipariş numarasını içerir.
6. **Ağ isteği doğrular ve kuyruğa alır.** Token, click ID imzası, IP ve (açıksa) HMAC imzası kontrol edilir. Yanıt anında döner, dönüşüm arka planda işlenir.
7. **Dönüşüm yayıncıya yazılır.** Fraud kuralları, tekilleştirme ve fiyatlandırma uygulanır; yayıncının paneline ve varsa yayıncı postback'ine yansır.

> **Dikkat:** En sık yapılan hata 3. adımdır. Click ID yalnızca landing sayfasında bir değişkende tutulur, kullanıcı birkaç sayfa gezdiğinde veya ödemeye geçtiğinde kaybolur. Değeri sunucu tarafı oturuma ya da kalıcı bir çereze yazın ve siparişin kendisine mutlaka kaydedin.

## Örnek S2S postback isteği

Bir S2S postback isteği, takip sunucusuna gönderilen, token, click ID ve dönüşüm detaylarını parametre olarak taşıyan basit bir HTTP çağrısıdır. Adfacten'de en sade hâli şöyledir:

```http
GET https://trk.adfacten.com/pb?token=<POSTBACK_TOKEN>&click_id=<CLICK_ID>&goal=sale&amount=250.00&currency=TRY&order_id=ORD-1001
```

Aynı alanları `POST` ile form veya JSON gövdesi olarak da gönderebilirsiniz; JSON'da sepet kalemleri için `items` dizisi desteklenir. Token'ı yol içinde de verebilirsiniz: `https://trk.adfacten.com/pb/<POSTBACK_TOKEN>`.

Parametrelerin anlamı:

| Parametre | Zorunlu mu? | Ne işe yarar? |
|---|---|---|
| `token` | Evet | Panelde Postback & piksel ekranındaki gizli postback token'ınız |
| `click_id` | Evet* | Tıklamanın kimliği (`clickid`, `cid`, `transaction_id`, `afclk` eş adları da kabul edilir) |
| `goal` | Hayır | Hedef anahtarı; gönderilmezse kampanyanın varsayılan hedefi |
| `amount` | CPS'te evet | Satış veya sepet tutarı |
| `currency` | Hayır | ISO-4217 para birimi kodu (varsayılan: kampanya para birimi) |
| `order_id` | Önerilir | Tekilleştirme anahtarı |
| `status` | Hayır | `pending` (varsayılan), `approved`, `rejected`, `reversed` |
| `customer_id` | RevShare'de | Tekrarlayan gelir için müşteri kimliği |
| `coupon` | Hayır | Kuponla atıf |
| `event_time` | Hayır | Olayın gerçekleştiği an (Unix saniye veya ISO-8601) |
| `test` | Hayır | `1` gönderilirse test dönüşümü sayılır, bakiyeyi etkilemez |

\* Click ID yoksa atıf `coupon` ile yapılabilir.

Başarılı istekte yanıt anında döner:

```json
{"status": "accepted", "event_id": "5b1f…"}
```

`accepted`, dönüşümün onaylandığı değil, isteğin kuyruğa alındığı anlamına gelir. Nihai sonucu (dönüşüm oluştu, tekrar olarak işaretlendi veya reddedildi) panelin **Son istekler** ekranında ve `conversion.*` webhook'larında görürsünüz. Hatalı isteklerde ise HTTP kodu ve `reason` alanı sorunun ne olduğunu söyler; bunları aşağıdaki sorun giderme bölümünde ele alıyoruz.

> **İpucu:** `event_time` alanını özellikle gecikmeli bildirimlerde kullanın. Sipariş dün gece verildiyse ve postback'i bugün toplu bir işle gönderiyorsanız, gerçek zamanı iletmek raporlarınızın doğru güne yazılmasını sağlar.

## Tekilleştirme ve idempotency: çift sayımı önlemek

Tekilleştirme, aynı dönüşümün birden fazla kez bildirilmesi durumunda yalnızca bir kez sayılmasını sağlayan kuraldır; idempotency (tekrar güvenliği) ise aynı isteği kaç kez gönderirseniz gönderin sonucun değişmemesidir. İkisi birlikte, sağlam bir postback entegrasyonunun temel taşıdır.

Gerçek hayatta tekrar kaçınılmazdır. Sunucunuz isteği gönderir, ağ yanıtı döner ama araya giren bir zaman aşımı yüzünden siz yanıtı göremezsiniz. Kodunuz isteği yeniden dener. Ya da hem piksel hem postback aynı siparişi bildirir. Tekilleştirme olmasa her senaryoda çift komisyon ödenirdi.

Adfacten'de anahtar `(order_id, goal)` ikilisidir. Aynı ikili ikinci kez geldiğinde yeni dönüşüm oluşmaz. Bunun pratik sonuçları şunlardır:

- Ağ hatası veya 503 yanıtı aldığınızda isteği tekrar göndermekten çekinmeyin; çift sayım riski yoktur.
- `order_id` göndermemek tekilleştirmeyi zayıflatır. Bu alan teknik olarak zorunlu değildir ama her entegrasyonda gönderilmelidir.
- Bir siparişte birden çok hedef varsa (ör. `registration` ve ardından `purchase`), farklı `goal` değerleri ayrı dönüşümler olarak sayılır; bu istenen davranıştır.
- Piksel ve postback'i birlikte çalıştırıyorsanız ikisinde de aynı `order_id` değerini kullanın.

Ayrıca fraud tarafında tekrar dönüşüm engeli devrededir: aynı tıklamadan anormal sayıda dönüşüm gelmesi gibi şüpheli örüntüler ayrıca işaretlenir. Konunun bu boyutunu [Affiliate Fraud Önleme](/blog/affiliate-fraud-onleme) rehberinde ayrıntılı ele alıyoruz.

## Durum güncelleme: bekliyor, onay, red ve iade

Durum güncelleme, bir dönüşümün yaşam döngüsünü (bekliyor → onaylandı / reddedildi → iade) aynı postback'in `status` parametresiyle yönetmektir. Ayrı bir entegrasyon kurmanız gerekmez; sipariş sisteminizdeki her durum değişikliğinde aynı isteği farklı bir durumla göndermeniz yeterlidir.

Tipik bir e-ticaret akışı şöyle işler:

1. Sipariş verildiğinde `status` göndermeden (veya `status=pending`) postback atılır. Dönüşüm **bekliyor** olarak düşer.
2. İade süresi dolup sipariş kesinleştiğinde aynı `order_id` ve `goal` ile `status=approved` gönderilir.
3. Sipariş iptal edilirse `status=rejected` gönderilir; yayıncıya hakediş yazılmaz.
4. Onaylanmış bir sipariş sonradan iade edilirse `status=reversed` gönderilir; yayıncı hakedişi otomatik geri alınır.

Burada bilinmesi gereken iki ince kural vardır. Birincisi, henüz onaylanmamış (bekleyen) bir dönüşüm için `reversed` gönderirseniz dönüşüm **reddedilir**, çünkü ortada geri alınacak bir para hareketi yoktur. İkincisi, yaşam döngüsünde tanımlı olmayan geçişler uygulanmaz; örneğin onaylı bir dönüşüme `rejected` göndermek **Son istekler** ekranında `invalid_status_transition` olarak görünür. Onaydan sonraki geri alma her zaman `reversed` ile yapılır.

Postback dışında iki yol daha vardır: toplu işlemler için `POST /v1/conversions/bulk-status` API ucu ve panelden CSV yükleme. Ay sonunda yüzlerce siparişi topluca onaylayan reklamverenler genellikle API'yi tercih eder.

> **Adfacten'de:** Reddederken sebep kodu kullanılır (`order_cancelled`, `order_returned`, `duplicate`, `invalid_lead`, `fraud` gibi). Yayıncı neden reddedildiğini görür; bu şeffaflık itirazları ve destek yükünü belirgin biçimde azaltır. Kısmi iadelerde tutarı düzeltmek de mümkündür.

## Yayıncı postback'leri ve makrolar

Yayıncı postback'i, affiliate ağının bir dönüşüm oluştuğunda veya durumu değiştiğinde yayıncının kendi takip sistemine gönderdiği bildirimdir. Yani S2S akışın ikinci yönüdür: reklamveren ağa bildirir, ağ da yayıncıya.

Kendi tracker'ını kullanan, birden fazla trafik kaynağını optimize eden veya reklam platformlarına dönüşüm geri besleyen yayıncılar için bu bildirim kritiktir. Adfacten'de yayıncı panelde **Postback'ler → Yeni postback** adımıyla adres tanımlar. Kapsam tüm kampanyalar ya da tek bir kampanya olabilir; hedef ve durum bazında filtrelenebilir (örneğin yalnızca `approved`). Yöntem olarak `GET` (makrolu URL) veya `POST` (gövde şablonu) seçilebilir.

Yayıncı kendi tıklama kimliğini de taşıyabilir: takip linkine `aff_click_id=<kendi ID'niz>` eklendiğinde bu değer postback'te `{aff_click_id}` makrosuyla geri döner. Örnek bir yayıncı postback adresi:

```http
GET https://tracker.sizin.com/postback?clickid={aff_click_id}&payout={payout}&currency={currency}&status={status}&goal={goal}
```

En çok kullanılan makrolar:

| Makro | Döndürdüğü değer |
|---|---|
| `{click_id}` | Adfacten click ID |
| `{aff_click_id}` | Yayıncının kendi tıklama ID'si |
| `{conversion_id}` | Dönüşüm kimliği (`cnv_…`) |
| `{offer_id}`, `{offer_name}` | Kampanya kimliği ve adı |
| `{goal}` | Hedef anahtarı |
| `{status}` | `pending`, `approved`, `rejected`, `reversed` |
| `{payout}`, `{currency}` | Yayıncı hakedişi ve para birimi |
| `{sale_amount}` | Satış tutarı (CPS) |
| `{order_id}` | Sipariş numarası |
| `{source}`, `{country}` | Trafik kaynağı ve ülke kodu |
| `{sub1}` … `{sub10}` | Linke eklenen alt parametreler |
| `{timestamp}` | Unix zaman damgası |

Teslimat güvenilirliği de tasarımın parçasıdır. 2xx dışındaki yanıtlarda istek, üstel geri çekilmeyle **72 saate kadar** yeniden denenir; her deneme teslimat günlüğünde istek, yanıt kodu ve süresiyle görünür. Teslimat "en az bir kez" garantisiyle yapıldığından aynı olay için birden çok çağrı gelebilir. Yayıncı tarafında tekilleştirme anahtarı olarak `{conversion_id}` + `{status}` ikilisini kullanmak gerekir. Test dönüşümleri (`test=1`) yayıncı postback'ini tetiklemez.

## Mobil uygulamalarda MMP ile postback

Mobil uygulama kampanyalarında postback'i reklamverenin sunucusu yerine MMP (mobile measurement partner, yani mobil ölçüm ortağı) gönderir. Kurulum ve uygulama içi olayları ölçen taraf MMP olduğu için, ağ ile MMP arasında doğrudan bir sunucudan sunucuya bağlantı kurulur.

Akış web'e çok benzer ama click ID'nin taşıyıcısı farklıdır:

1. Yayıncının takip linki tıklanır, ağ click ID üretir.
2. Kullanıcı MMP'nin tracking linkine yönlendirilir; bu linkte MMP'nin "click id" parametresine `{click_id}` makrosu yerleştirilmiştir.
3. Kullanıcı uygulama mağazasından uygulamayı indirir ve açar. MMP kurulumu bu tıklamaya atfeder.
4. MMP, ağın sağlayıcıya özel postback ucunu çağırır.

Adfacten'de uç formatı şöyledir:

```http
GET https://trk.adfacten.com/mmp/<saglayici>?token=<POSTBACK_TOKEN>&click_id={clickid}&goal={event_name}&amount={revenue}&currency={currency}
```

`<saglayici>` yerine `appsflyer`, `adjust`, `branch`, `singular` veya `kochava` yazılır ve raporlarda kaynak olarak görünür. Parametreler ve yanıtlar web postback'iyle aynıdır. `goal` gönderilmezse olay **install** (kurulum) kabul edilir; bu da CPI kampanyaları için ek ayar gerektirmez.

CPE (cost per engagement, yani uygulama içi etkileşim başına ödeme) kampanyalarında ise kampanyada `registration`, `purchase` gibi hedefler tanımlanır ve MMP'deki olay adları bu anahtarlarla eşlenir. Mobil modellerin ekonomisini [Performans Pazarlama Modelleri](/blog/performans-pazarlama-modelleri) yazısında karşılaştırmalı olarak inceliyoruz.

## Tıklamasız atıf: attribution token

Attribution token (atıf token'ı), link tıklaması olmadan gerçekleşen satışları doğru yayıncıya bağlamak için üretilen, click ID ile aynı güvenlikte, imzalı ve süreli bir atıf anahtarıdır. Yapay zekâ asistanlarının önerileri, podcast'ler, sosyal içerikler ve API üzerinden yapılan satışlar bu kapsama girer.

Klasik postback, bir tıklamanın var olduğunu varsayar. Oysa bir kullanıcı bir yapay zekâ asistanından ürün önerisi alıp satın alma akışına doğrudan geçebilir ya da bir podcast'te duyduğu referans kodunu sepette girebilir. Bu kanallarda click ID yoktur; atıf token'ı bu boşluğu doldurur.

Token, API üzerinden üretilir:

```http
POST /v1/attribution-tokens
Authorization: Bearer af_live_…

{ "offer_id": "off_…", "channel": "agent", "sub": { "sub1": "assistant-x" } }
```

`channel` değeri `api`, `agent`, `podcast`, `social` veya `offline` olabilir ve raporlarda kanal kırılımı olarak görünür. Token kullanıcının satın alma akışına iletilir; örneğin sepetteki referans alanına ya da bir deep link parametresine. Reklamveren dönüşümü bildirirken `click_id` yerine `attribution_token=<token>` gönderir; doğrulama, tekilleştirme ve fiyatlandırma aynen uygulanır.

Token'ın süresi kampanyanın atıf penceresi kadardır. Süresi dolmuş, başka reklamverene ait veya değiştirilmiş token'lar reddedilir; ayrıca kampanyada "token ile atıf" kaynağının açık olması gerekir. Yapay zekâ ajanları bu akışı Adfacten'in MCP sunucusu üzerinden de kullanabilir. Konunun geleceğe dönük tarafını [Yapay Zekâ Ajanları ve Affiliate Marketing](/blog/yapay-zeka-ajanlari-affiliate-marketing) yazısında ve [yapay zekâ ajanları](/yapay-zeka-ajanlari) sayfamızda bulabilirsiniz.

## Postback güvenliği: gizli token, HMAC imzası ve IP kısıtı

Postback güvenliği, ağa yalnızca gerçek reklamverenin gerçek dönüşümleri bildirebilmesini sağlayan katmanlardan oluşur: gizli token, isteğe bağlı HMAC imzası, IP izin listesi ve imzalı click ID. Bu katmanlar olmadan kötü niyetli biri sahte postback'lerle komisyon üretmeye çalışabilir.

**Gizli postback token.** Her istekte zorunludur ve yalnızca sunucu tarafında tutulmalıdır. Kaynak koda gömülmemeli, ön yüz (frontend) koduna veya piksele asla yazılmamalıdır. Erişimi olan kişi sayısını asgaride tutun.

**İmzalı click ID.** Click ID'ler ağ tarafından imzalanır ve süreli üretilir. Uydurma veya bozulmuş bir click ID ile gelen istek `invalid_click_id` ile reddedilir. Başka bir reklamverene ait click ID ise `offer_not_owned_by_advertiser` hatası verir.

**HMAC-SHA256 imzası (önerilir).** Token'a ek olarak her isteği panelde gösterilen imza anahtarıyla imzalayabilirsiniz. Yöntem şöyledir:

1. `ts` parametresine şu anki Unix zamanını (saniye) ekleyin. ±5 dakikadan eski istekler reddedilir; bu, ele geçirilmiş bir isteğin sonradan tekrar oynatılmasını engeller.
2. `sig` hariç tüm parametreleri, anahtarları küçük harfle, anahtara göre alfabetik sıralayın ve `anahtar=değer` çiftlerini `&` ile birleştirin. Değerler URL-çözülmüş (ham) hâliyle kullanılır.
3. `sig = hex(HMAC-SHA256(imza_anahtarı, birleştirilmiş_metin))` hesaplayıp isteğe ekleyin.

Komut satırından örnek:

```bash
secret='IMZA_ANAHTARI'
ts=$(date +%s)
q="amount=250.00&click_id=$CLICK_ID&currency=TRY&goal=sale&order_id=ORD-1001&token=$TOKEN&ts=$ts"
sig=$(printf '%s' "$q" | openssl dgst -sha256 -hmac "$secret" -hex | sed 's/^.* //')
curl "https://trk.adfacten.com/pb?$q&sig=$sig"
```

İmzaya geçtikten sonra paneldeki **İmza zorunlu** seçeneğini açarak imzasız istekleri tamamen reddedebilirsiniz. Böylece token sızsa bile imza anahtarı olmadan geçerli istek üretilemez.

**IP izin listesi.** Postback'lerin yalnızca kendi sunucularınızdan gelmesini istiyorsanız izinli IP'leri tanımlayabilirsiniz. Listede olmayan bir adresten gelen istek `ip_not_allowed` ile reddedilir. Sunucu altyapınızı değiştirdiğinizde bu listeyi güncellemeyi unutmayın.

Geliştirici ekibiniz PHP, Node.js ve Python örneklerinin tamamını [geliştirici portalında](https://developers.adfacten.com) bulabilir.

## Postback sorun giderme kontrol listesi

Postback sorunlarının büyük çoğunluğu dört nedenden kaynaklanır: click ID'nin kaybolması, yanlış token, imza hesaplama hataları ve test ile canlı ortamın karıştırılması. Aşağıdaki liste, en olası nedenden en az olasıya doğru sıralanmıştır.

1. **Landing URL'inde click ID var mı?** Kampanyanın landing adresinde `{click_id}` makrosunun bulunduğunu veya `afclk` parametresinin sayfaya ulaştığını tarayıcı adres çubuğundan doğrulayın. Ara yönlendirmeler sorgu parametrelerini silebilir.
2. **Click ID siparişe kaydediliyor mu?** Test siparişi verip veritabanında ilgili alanın dolu olduğunu kontrol edin. Boşsa sorun oturum yönetimindedir.
3. **Postback gerçekten gönderiliyor mu?** Sunucu günlüklerinizde giden isteği ve dönen HTTP kodunu arayın. Sipariş durumu tetikleyicisi (ör. "ödeme alındı" olayı) bazen hiç çalışmaz.
4. **HTTP kodu ne diyor?**
   - `400 missing_click_id` / `invalid_click_id`: click ID boş, kesilmiş veya değiştirilmiş.
   - `401 invalid_token`: token yanlış veya eski. `bad_signature`: imza metni hatalı sıralanmış ya da URL-kodlu değerlerle hesaplanmış. `signature_expired`: `ts` 5 dakikadan eski ya da sunucu saatiniz kaymış. `signature_required`: İmza zorunlu açık ama istek imzasız.
   - `403 ip_not_allowed`: sunucu IP'niz izin listesinde değil. `offer_not_owned_by_advertiser`: click ID başka bir reklamverenin kampanyasına ait. `advertiser_inactive`: hesap pasif.
   - `503 not_ready`: geçici durum; aynı isteği tekrar gönderin.
5. **İstek `accepted` ama panelde dönüşüm yok mu?** **Son istekler** ekranına bakın; dönüşüm tekrar (duplicate) olarak işaretlenmiş, fraud kuralına takılmış veya geçersiz durum geçişi (`invalid_status_transition`) olabilir.
6. **Tutar veya para birimi yanlış mı?** Ondalık ayırıcı olarak nokta kullanın (`250.00`), binlik ayırıcı eklemeyin. `currency` gönderilmezse kampanyanın para birimi varsayılır.
7. **Test dönüşümleri raporda görünmüyor mu?** `test=1` ile gönderilenler raporlarda ayrı filtrelenir ve bakiyeyi etkilemez. Canlıya geçerken bu parametreyi kaldırmayı unutmayın.
8. **Sunucu saatiniz doğru mu?** İmzalı isteklerde saat kayması `signature_expired` hatasının sessiz nedenidir. NTP senkronizasyonunu kontrol edin.

> **İpucu:** Postback'i sipariş oluşturma isteğinin içinde senkron göndermek yerine bir iş kuyruğuna atın. Böylece takip sunucusuna ulaşılamadığında kullanıcının ödeme deneyimi etkilenmez ve başarısız istekler otomatik yeniden denenir.

## Adfacten postback test aracıyla uçtan uca doğrulama

Adfacten'in postback test aracı, sahte bir tıklama üreterek size örnek postback URL'ini veren ve gönderdiğiniz isteğin uçtan uca işlendiğini gösteren bir doğrulama ekranıdır. Canlı trafiğe çıkmadan entegrasyonun doğru çalıştığından emin olmanın en hızlı yoludur.

Önerilen test sırası şöyledir:

1. Panelde **Test aracı** ekranını açın ve test tıklaması üretin. Araç size gerçek formatta bir click ID ve hazır postback URL'i verir.
2. Bu click ID ile landing sayfanızı ziyaret edin ve sitenizde test siparişi tamamlayın. Böylece click ID'nin landing'den siparişe kadar taşındığını da sınamış olursunuz.
3. Sunucunuzun gönderdiği postback'i `test=1` ile işaretleyin.
4. Test aracında ve **Son istekler** ekranında isteğin `accepted` olduğunu, dönüşümün doğru hedef, tutar ve para birimiyle oluştuğunu kontrol edin.
5. Aynı `order_id` ile isteği bir kez daha gönderin ve yeni dönüşüm oluşmadığını doğrulayın.
6. `status=approved` ve ardından `status=reversed` göndererek durum geçişlerini test edin.
7. İmza kullanıyorsanız bilerek yanlış bir `sig` gönderip `bad_signature` hatası aldığınızı görün; ardından **İmza zorunlu** seçeneğini açın.

Bu yedi adımı geçen bir entegrasyon, canlı trafikte büyük olasılıkla sorunsuz çalışır. Reklamveren tarafında programın geri kalanını kurmak için [Affiliate Programı Nasıl Kurulur?](/blog/affiliate-program-kurma) rehberine göz atabilirsiniz.

## Adfacten ile S2S takibe nasıl başlanır?

Adfacten'de S2S postback'e başlamak için reklamveren hesabı açıp kampanyanızın landing URL'ine `{click_id}` makrosunu eklemeniz ve Postback & piksel ekranındaki token'la ilk test isteğinizi göndermeniz yeterlidir. 2014'ten beri performans pazarlamada çalışan Adfacten, S2S postback'i öncelikli takip yöntemi olarak sunar; piksel ve MMP entegrasyonları da aynı tekilleştirme ve fraud kurallarından geçer.

Reklamverenseniz [reklamveren sayfamızda](/reklam-veren) takip ve fraud koruma özelliklerinin tamamını inceleyebilir, doğrudan [reklamveren hesabı oluşturabilirsiniz](https://app.adfacten.com/signup?type=advertiser). Yayıncıysanız kendi tracker'ınızı yayıncı postback'leriyle bağlamak için [yayıncılar sayfasına](/yayincilar) göz atın ya da [yayıncı olarak kaydolun](https://app.adfacten.com/signup?type=publisher). Teknik ekibiniz ise tüm uç noktaları, webhook'ları ve kod örneklerini [developers.adfacten.com](https://developers.adfacten.com) adresinde bulabilir.

## Sık sorulan sorular

### Postback nedir, basitçe anlatır mısınız?

Postback, bir kullanıcı satın alma veya kayıt gibi bir hedefi tamamladığında, reklamverenin sunucusunun affiliate ağına gönderdiği kısa bir HTTP isteğidir. İstekte tıklamayı tanımlayan click ID, hedef türü ve tutar gibi bilgiler bulunur. Ağ bu bilgiyle dönüşümü doğru yayıncıya yazar ve komisyonu hesaplar. Tarayıcı devreye girmediği için çerezlerden bağımsızdır.

### S2S postback ile piksel arasındaki fark nedir?

Piksel, dönüşüm sayfasında kullanıcının tarayıcısında çalışan bir kod parçasıdır ve çerez okur; reklam engelleyici, ITP veya sayfanın yarıda kapanması onu etkisiz bırakabilir. S2S postback ise siparişi onaylayan sunucudan doğrudan gönderilir. Bu yüzden daha az veri kaybı yaşanır, iade ve onay gibi durum güncellemeleri de yalnızca sunucu tarafında yapılabilir.

### Postback URL nedir ve nereden alınır?

Postback URL, dönüşüm bildirimlerinin gönderileceği adrestir. Reklamveren tarafında bu adres affiliate ağının takip sunucusudur ve size özel bir postback token içerir. Adfacten'de adres ve token, panelde Postback & piksel ekranında hazır gelir. Yayıncı tarafında ise postback URL, ağın dönüşümleri yayıncının kendi takip sistemine bildirdiği adrestir.

### Click ID nedir, neden saklamam gerekiyor?

Click ID, her tıklamaya özel üretilen, imzalı ve süreli bir kimliktir. Kullanıcı landing sayfanıza geldiğinde URL'de taşınır. Bu değeri oturuma ve siparişe kaydetmezseniz, dönüşüm gerçekleştiğinde hangi yayıncıdan geldiğini ağa söyleyemezsiniz. Click ID'yi saklamamak, S2S entegrasyonlarında dönüşüm kaybının en sık nedenidir.

### Aynı postback iki kez gönderilirse çift komisyon oluşur mu?

Doğru kurulmuş bir sistemde oluşmaz. Adfacten'de aynı order_id ve goal ikilisi ikinci kez geldiğinde yeni dönüşüm yaratılmaz. Bu sayede ağ hatası veya zaman aşımı durumunda isteği gönül rahatlığıyla tekrarlayabilirsiniz. Yalnızca status değeri farklıysa, örneğin onaydan iadeye geçiş, mevcut dönüşümün durumu güncellenir.

### Mobil uygulamalarda postback nasıl çalışır?

Mobil kampanyalarda kurulum ve uygulama içi olaylar genellikle bir MMP (mobil ölçüm ortağı) tarafından ölçülür. Click ID, tracking linki üzerinden MMP'ye aktarılır; kurulum veya satın alma olduğunda MMP, affiliate ağının sağlayıcıya özel postback ucunu çağırır. Böylece CPI ve CPE kampanyaları da sunucudan sunucuya ölçülür.