performetra
Publishers Start a campaign

Technology

Tracking you can audit, not just trust

Performance marketing is an accounting exercise wearing a marketing costume. If the counting is wrong, everything downstream is wrong. Here is exactly how ours works.

Overview

How Performetra tracking works

Attribution on Performetra is server to server. A unique click ID is stamped on every click, travels through the user journey, and comes back on a postback fired by your server or your mobile measurement partner — AppsFlyer, Adjust, Branch, Singular, Airbridge or Kochava. No third-party cookies, no browser dependency, no parallel source of truth: your system counts, ours reconciles.

Before any conversion becomes billable it is screened for duplicate devices, click-to-install-time anomalies, emulators, datacentre IPs and geo mismatch. The screened log drives your dashboard, your CSV export and your invoice — the same log, in the same order. Advertisers can read why postbacks beat pixels; publishers get the same click ID and sub-IDs back for their own reconciliation.

At a glance

Method
S2S postback with deterministic click ID match
MMPs
AppsFlyer, Adjust, Branch, Singular, Airbridge, Kochava
Fallback
Pixel, only where no server event exists
Screening
Every conversion, before it is billable
Export
CSV schedule or pull API, into your warehouse
Retention
Logs 24 months, lead data dispute-window only

The chain

What happens between a click and an invoice line

Click

The publisher sends a click to a tracking URL. We stamp a unique click ID, record sub-publisher, device, IP-derived geo and timestamp, then redirect to your destination in a single hop.

Attribution

Your MMP or backend attributes the conversion. The click ID travels through the journey and comes back to us on the postback, so the match is deterministic rather than probabilistic.

Screening

Before the conversion is billable it passes duplicate, timing, device, geo and behavioural checks. Anything flagged is quarantined with a reason code, not silently dropped.

Reconciliation

At month end our log is compared against yours. Differences are investigated line by line. You are invoiced from the reconciled set — nothing else.

Integration

Three ways to connect, all of them boring

Boring is the goal. Every integration path below is a configuration change on your side, not a sprint.

MMP
App campaigns. We are added as a partner in AppsFlyer, Adjust, Branch, Singular, Airbridge or Kochava. Attribution stays entirely inside your MMP.
S2S
Web and CRM. Your server calls our postback URL on the conversion event, passing the click ID and, optionally, order value and status.
Pixel
Fallback. A conversion pixel on the thank-you page. Simplest to deploy, weakest to fraud, so we use it only where no server option exists.
API
Both directions. Pull click and conversion data into your warehouse, or push status updates back to reject conversions programmatically.
postback / example

GET https://track.performetra.com/postback
  ?click_id={click_id}
  &event=purchase
  &payout=auto
  &order_value=2499.00
  &currency=INR
  &status=approved
  &txn_id={your_order_id}

200 OKIdempotent on txn_id

Duplicate txn_id values are rejected, so a retried postback never creates a second billable conversion.

Fraud control

The checks that run before anything is billable

No vendor eliminates fraud. What matters is catching it before you pay for it, and being specific about what was caught.

Device & duplicate

Duplicate device identifiers, repeat conversions inside the dedupe window, and reused click IDs are blocked at ingestion.

Timing anomalies

Click-to-install time distributions that spike below ten seconds or cluster unnaturally indicate click flooding or injection. Both get flagged.

Origin checks

Datacentre IP ranges, known VPN and proxy exits, emulator fingerprints and geo mismatch against the offer’s allowed countries.

Lead validation

Syntax and deliverability checks, duplicate matching across the whole network rather than one campaign, and optional live-call verification.

Behavioural depth

For app and e-commerce, post-conversion behaviour is compared against the campaign baseline. Users who never open again are a quality signal, not a rounding error.

Publisher scoring

Every sub-publisher carries a rolling quality score. Falling scores trigger review before an advertiser has to complain.

Data handling

  • Purpose limitation. Campaign data is used to run and reconcile that campaign. Nothing else.
  • No cross-advertiser pooling. One advertiser’s performance never informs another’s pricing.
  • Retention. Click and conversion logs kept 24 months for dispute resolution, then purged.
  • Lead data. Transmitted over TLS, delivered to your endpoint, and not retained beyond the dispute window.
  • Consent trail. For regulated lead campaigns we store source URL, timestamp and consent text with each record.

Full detail in our privacy policy.

Reporting

Everything we can see, you can see

There is no advertiser view and internal view. The same conversion log drives your dashboard, your export and your invoice.

  • Real-time conversion feed with click ID, sub-publisher, device, geo, timestamp and status.
  • Approval and rejection rates per publisher, with reason codes.
  • Pacing against daily and monthly caps, with alerts before a cap is hit.
  • Cohort view for app and subscription campaigns — retention and repeat behaviour, not just the install.
  • Scheduled CSV export or pull API into your own warehouse.

Technical questions

No, and we would rather you did not. Your MMP or CRM should be the system of record. Our platform exists to route traffic, apply caps and pay publishers; billing follows your numbers after reconciliation.

AppsFlyer, Adjust, Branch, Singular, Airbridge and Kochava, plus direct server-to-server postbacks for in-house attribution. Integration is a configuration step, not a development project.

For iOS we work with your MMP’s SKAN and aggregated-measurement setup, agree a conversion-value schema up front, and price against the events that remain observable. Where signal is genuinely unavailable we price on the model that is measurable rather than pretending otherwise.

No. Primary attribution is server to server with a click ID passed through the redirect and returned on the postback. Cookies are a fallback for web campaigns where no server integration exists.

Yes. Scheduled CSV export, or a pull API with click and conversion endpoints. Several advertisers land it straight into BigQuery and reconcile automatically.

Click ID (required), event name, order value and currency, status, your transaction ID, and up to five custom fields. Calls are idempotent on your transaction ID, so a retried postback can never create a second billable conversion. A worked example is shown above on this page.

Three layers: idempotency on your transaction ID, device-and-click de-duplication inside a configurable window, and network-wide duplicate matching for lead campaigns. Duplicates are quarantined with a reason code, not silently dropped, so both sides can audit them.

Clicks and conversions appear in reporting within seconds of the postback. Approval status may update later — for example when a lead fails validation or an order reverses — and every status change is timestamped in the log you can export.

Daily and monthly caps per campaign and per publisher, with alerts before a cap is reached and automatic pause when it is. Budget can never overrun by more than the in-flight clicks at the moment the cap trips.

Campaign data is used only to run and reconcile that campaign — no cross-advertiser pooling, no marketing profiles. Click and conversion logs are retained 24 months for dispute resolution; lead data only for the agreed dispute window. Full detail in the privacy policy.

Next step

Send us your postback spec.

We will map it, wire a test conversion and show you the log entry it produces — before you commit budget to anything.

Talk to an integration manager How advertisers work with us