Skip to content
Docs

Getting started

Concepts

Tenants, advertisers, partners, offers, goals, payouts, tracking domains and how they fit together.

Metrixed is one platform for affiliate networks, in-house affiliate programs, mobile attribution, media buying, iGaming affiliate programs and lead distribution. The data model is the same in every mode; a tenant's modes change defaults, vocabulary and navigation only.

The cast

ConceptWhat it isNotes
TenantOne network or workspace. Everything is isolated by tenant with row-level security.Users can belong to several tenants. API keys belong to one.
AdvertiserThe party that pays for results: a brand, an app, a lead buyer.Carries billing mode, postback security (none, token, ip, hmac) and portal access.
PartnerThe party that sends traffic: affiliate, publisher, media buyer, sub-network, ad network.Partners and advertisers are principals inside a tenant, not tenants.
OfferWhat a partner promotes: a destination URL plus rules, goals and payouts.The unit you send traffic to.
GoalA result you pay for on an offer: install, lead, sale, FTD.Identified by a stable key that postbacks send as goal.
Payout and revenue entryWhat the partner earns and what the advertiser pays, per goal.Many entries can exist; selection is by priority, then specificity, then the default entry.
Tracking domainThe branded host that serves links and receives postbacks, usually a CNAME to the edge.One domain can speak several link styles.
ClickOne request to a tracking link. Stored with its decision and reason.Valid and invalid clicks are both kept.
ConversionA recorded result, with a status and a full history.Append-only: changes add events, they never overwrite.

How the pieces connect

text
partner --click--> tracking domain --302--> offer destination (advertiser)
                         |                         |
                      click event            conversion (postback / pixel / S2S / SDK)
                         v                         v
                  matched by click_id -> goal -> payout entry -> status -> ledger -> statement
  1. A partner gets a tracking link for an offer, on a tracking domain.
  2. A visitor clicks. The edge redirect applies rules, caps and fraud checks, writes a click with a unique click_id, and sends the visitor to the destination with macros filled in.
  3. The advertiser reports a result back with that click_id. Ingest attributes it to the click, validates it, prices it with the matching payout entry, assigns a status and publishes the conversion.
  4. Reports read the conversion. The ledger turns approved conversions into balances; statements and payout runs pay partners; invoices bill advertisers.

Conversion status

A conversion has one of: pending, approved, rejected, cancelled, extended, flagged, scrubbed. The initial status comes from, in order: the goal's default_status, the offer's default_conversion_status, pending when approval is required, a status sent by a trusted advertiser, flagged for a high click fraud score, cap and scrub rules. Later changes (manual approval, advertiser reversal, clawback) are recorded as events with a reason and actor, and reports restate the original day, so history stays reconcilable.

Access, visibility and approval

Offers are public, require_approval or private. A partner's access to an offer is a per-partner setting that also carries payout overrides, caps and custom scrub, so everything about "partner X on offer Y" lives in one place. New partners can apply through the portal, and staff decide applications.

Tenants, portals and roles

Staff use the admin portal with roles and permissions. Partners and advertisers get their own white-label portals with the same engine: portal reports mask columns (a partner never sees revenue or advertiser names) but the numbers are the same numbers.

Next