Campaign overview
Understand your performance without the technical complexity.
Explore a sample campaign
Generate a fictional customer, publisher, click and conversion to see how tracking works. Each run adds a new test dataset.
| Campaign | Customer | Conversion rule | Payout | Status |
|---|
Campaigns
All your campaigns and their conversion rules.
Database-backed search; no loaded-row limit.
| Campaign | Customer | Conversion rule | Payout | Status | Action |
|---|
Create a campaign
Create the campaign first, then configure flexible conversion goals in Events & Goals. The legacy milestone selector is retained only for backwards compatibility with existing test campaigns.
Events & Goals
Define generic conversion goals and direct event rules without hard-coding one advertiser workflow.
Generic conversion engine
Use any lowercase event code. Qualify on one event, N events, cumulative USD value, or manual approval. Goals stay linked to the original Vexa attribution.
Create / edit generic goal
Goal directory
0Database-backed search · 20 per page.
| Goal | Campaign | Trigger | Threshold | Payout | Status | Conversions | Action |
|---|
Manual goal approval
Only for goals whose type is Manual approval. The user must already be deterministically attributed to that campaign.
Direct event conversion rule
Example: app_install = track only; registration_complete = conversion without payout; first_purchase = payable conversion.
Campaign events
0| Campaign | Event | Type | Payment | Repeat rule |
|---|
Supplier-specific payout
Override the standard event payout for one publisher on a specific campaign. This can also disable payment for that supplier.
| Campaign | Event | Publisher | Payment |
|---|
Publishers
Partners who promote your campaigns and send traffic.
Database-backed search; no loaded-row limit.
| Publisher | Status | Postback destination | Added | Action |
|---|
Edit publisher
Edit settings without changing API keys, earnings or account relationships.
Add a publisher
Supplier Operations
Operate publisher onboarding, campaign access, sub-affiliates and approved campaign assets from one searchable workspace.
Database-backed supplier operations search.
Publisher onboarding profile
Verification is operator-recorded metadata only; this module does not perform external KYC.
Publisher directory
| Publisher | Onboarding | Verification | Terms | Assignments | Action |
|---|
Campaign access & applications
Approving an application creates or re-enables that publisher's Vexa tracking-link assignment. Pausing or rejecting disables the assignment without deleting history.
| Publisher | Campaign | Status | Tracking link | Reviewed | Actions |
|---|
Sub-affiliate registry
Registered sub-affiliates
| Publisher | Sub ID | Name | Status | Action |
|---|
Campaign asset
Asset inventory
| Campaign | Asset | Type | Status | Action |
|---|
Scope boundary
Supplier Operations manages Vexa publisher metadata and campaign access. External KYC verification, MFA/SSO, bank payouts and legal contract execution are intentionally not represented as automated here.
Partner Workspaces
Create separate scoped customer and publisher previews from fictional accounts. No operator secrets shared.
Preview access, not production user accounts
Keys expire within 72 hours and can be revoked. Browser preview cannot edit campaigns, payouts, or invoices. Do not use this instead of permanent sign-in with MFA/RBAC.
Issue demo workspace credential
Save this key now — shown once
Open /partner in a separate browser tab and enter the key. Never put it in the URL.
Partner preview URL
Only fictional accounts can be accessed through these temporary credentials.
Customer view hides internal publisher and supplier-cost details. Publisher view hides advertiser charges and other publishers.
Issued preview grants
| Label | Role / account | Expires (UTC) | Status | Action |
|---|
Identity & Access
Provision tenant-scoped customer and publisher users with role-based read access, tracked sessions and TOTP MFA.
Core access boundary
Vexa now supports active customer/publisher accounts, password rotation, login lockout, revocable tracked sessions, access roles and optional/required TOTP MFA. Enterprise SSO/OIDC can be added later as an external identity federation option.
Create account user
Copy this one-time password
Shown once. The user must change it on first sign-in. Never place credentials in URLs.
Account workspace
Each account user receives an individual sign-in. Tenant isolation is fixed to the assigned customer or publisher, while access role controls which read-only sections can be opened.
Viewer: campaigns. Analyst: campaigns + activity. Finance: campaigns + activity + finance. Manager: all current workspace read views. MFA can be optional or required.
Provisioned users
Database-wide search with server-side pagination.
Search across all provisioned users.
| User | Workspace | Access | MFA | State | Last sign-in | Actions |
|---|
Privacy & Governance
Configure operational privacy controls without embedding one advertiser or one regulation into Vexa.
Operational controls, not legal advice
Vexa can enforce configured consent and country restrictions, manage retention, pseudonymize subject-linked operational records and keep privacy access/audit logs. Your organization remains responsible for deciding the lawful basis, notices and retention periods that apply.
Customer privacy policy
Retention operation
Retention removes only eligible non-financial operational records. Financial ledger rows are never auto-deleted by this workflow.
Choose a customer and preview retention.
Record consent decision
Vexa stores a one-way subject hash in the consent ledger, not the raw user identifier.
Recent consent records
| Subject hash | Purpose | Status | Source | UTC |
|---|
Create subject request
Subject-request queue
Preview and completion require the original opaque user ID again; Vexa does not store it in the request record.
| Request | Subject hash | Type | Status | Created | Actions |
|---|
Last request preview
No subject export preview loaded.
Privacy access log
| Action | Resource | Subject hash | UTC |
|---|
Chained privacy audit
| Action | Entity | Hash | UTC |
|---|
Customers
Manage customer accounts across the VimoMR Vexa ecosystem.
| Customer | Status | Added | Manage |
|---|
Add a customer
Customer details and API credentials
The original customer key stays active and cannot be displayed or recovered here. New credentials are mobile-ingest only and limited to DEMO ONLY customers with a sandbox Android app. No payout, postback or forwarding setting is changed.
Issue a separate Android sandbox credential
Existing keys remain unchanged. Copy the newly issued key once, then store it privately in the relay under VEXA_CUSTOMER_API_KEY. Do not enable forwarding until the ingestion safety checks pass.
Individually revocable mobile-only credentials
| Label | Scope | Status | Issued (UTC) | Action |
|---|
Recent security changes
| Action | When (UTC) |
|---|
Tracking links
Give each publisher a unique link to measure traffic and attribution.
Generate a publisher link
Choose a campaign and publisher. We'll take care of the tracking identifier.
| Campaign | Publisher | Tracking URL |
|---|
The placeholder {publisher_user_id} is replaced by the partner's own user identifier. Use fictional identifiers for this demonstration.
Reports & events
See which events were received and which conversions were approved.
Cross-tab performance
Filter by date, campaign, publisher or event. Select the dimensions for a pivot-style report.
| Event | Campaign | Publisher | Occurred (UTC) |
|---|
| Campaign | Publisher | Payout | Status | Approved (UTC) |
|---|
Core Operations
Campaign control, click-only and event reporting, and read-only readiness inspection.
What is operational?
Core campaign creation, tracking, routing, event intake and reporting can be inspected here. Campaign pause/resume is restricted to fictional DEMO ONLY campaigns and requires an audit explanation. No test here sends external HTTP or changes an invoice.
Campaign performance — 30 days
Includes clicks with no events. Event and conversion counts are recorded data, not estimated installs. Financial totals are unadjusted ledger amounts and may cover periods outside the 30-day activity window.
| Campaign | Active? | Links | Clicks | Events | Approved conversions | Advertiser charge | Publisher cost |
|---|
Campaign readiness & controlled status
Select a campaign to inspect its readiness.
Click → Event inspector
Read-only trace for fictional demo click IDs. Does not expose user IDs, email addresses, or raw device identifiers.
Paste a click ID from a fictional demo journey.
Campaign Center
Search by permanent campaign ID, external ID, campaign name or customer.
Search campaigns
Results are fetched from the database, not guessed or generated. Select a campaign to edit its settings.
| Campaign / ID | Customer | External ID | Platform | Open |
|---|
Campaign profile and preview URL
This screen updates campaign metadata only. Delivery restrictions are managed separately in Delivery Controls. The configured destination URL is unchanged.
Inbound Event Studio
Receive, normalize and validate authenticated advertiser events before attribution, goals and postbacks.
What is active?
Authenticated customer server events can use POST /v1/events or POST /v1/inbound. Campaign-scoped integrations can use POST /v1/inbound/{campaign_id}. Alias and contract enforcement is operator-configured and audited; conversions and payouts still require a separately configured goal or event rule.
Advertiser inbound endpoints
Use server-side customer credentials in the Authorization header. Never put API keys in URLs or browser code.
POST /v1/inbound — global advertiser inbound endpoint
POST /v1/inbound/{campaign_id} — campaign-scoped endpoint with click/campaign ownership validation
Authorization: Bearer <customer server API key>
All three routes use the same attribution, deduplication, goal qualification and postback staging pipeline.
Inbound event alias mapping
For example, advertiser signup_done → Vexa registration_complete. Enforce mode rewrites the incoming code to the normalized event before goal/event-rule evaluation.
| Campaign | Incoming event | Normalized event | Mode |
|---|
Event validation contracts
Require an attributed user, survey reference, or a maximum event age. Enforcement rejects events that fail the configured contract.
| Campaign | Event | Mode | Requirements |
|---|
No-write inbound event inspector
Simulate event mapping and contract checks without inserting an event, click, conversion or postback.
Choose a campaign and run an inspection.
Web Measurement Pixels
Consented browser observations connected to recorded Vexa clicks.
What is measured?
One pixel receipt per registered event and recorded click. No personal data, conversion, reward, invoice or postback is created. A browser pixel is not proof of a mobile app installation.
Create a web pixel
The public pixel URL is shown once, with a secure opaque token. Only click IDs from the matching fictional campaign are accepted; consent=1 is mandatory.
Create a tracking-only pixel to generate the one-time image and JavaScript templates.
Pixel inventory and receipts
| Campaign | Event | Enabled | Unique receipts |
|---|
No inspection has been run.
Recent consented receipts
| Event | Click ID | Time (UTC) |
|---|
Integration & Developer Center
Public API discovery, request examples, connector configuration, imports, test harnesses, postbacks and macros.
Developer API & code snippets
OpenAPI is public metadata. Generated examples use placeholders and never expose stored credentials.
Choose an endpoint and generate a server-side example.
Connector registry
Configuration and field mappings only; provider secrets are never stored here.
| Connector | Customer | Provider | Direction | Environment | Approval | Action |
|---|
CSV import
Preview before applying. Imports update existing campaign metadata or event aliases; they never create payouts or send HTTP.
Paste CSV and preview it first.
Recent import jobs
| ID | Customer | Type | State | Applied | Created |
|---|
No-write event test harness
No test run yet.
Postback sample generator
No sample generated yet.
Predefined event library
Choose a campaign and select standard events. They start as tracking-only; you decide later if they count as conversions or carry a payout.
Tracking links, preview and safe sandbox
A preview inspects the advertiser's preview landing page. The sandbox generates an example redirect without creating clicks, events or payouts.
Choose a tracking link to inspect.
Multi-destination postback subscriptions
Register multiple GLOBAL, PUBLISHER, CAMPAIGN or EVENT-specific destinations. Enabled subscriptions now also stage matched, idempotent sandbox outbox records for newly accepted customer events. No outbound HTTP is sent.
| Name | Scope | Method | Status filter | Dry-run |
|---|
Postback matching simulator
Shows which destinations would match a given campaign event. It sends zero external requests.
No dry-run yet.
Tracking macro catalogue
Supported metadata is marked by its actual source. These are not guarantees of SDK-level attribution.
| Variable | Source | Meaning |
|---|
Vexa Demo Journey
A coordinated, repeatable fictional demonstration across Vexa modules.
One-click integrated showcase
Generates two fictional publishers, one campaign, tracking clicks, customer-key-authenticated sandbox event processing, an Android click-linked candidate first-open plus a linked in-app event, event conversion rules, two sandbox postback destinations, mobile evidence reviews and an internal financial ledger with a draft subscription invoice. No external delivery, store-verified app install or real payment is created. Limited to eight showcase datasets per 24 hours.
Build or inspect a Vexa showcase
Each run adds one fully labeled fictional dataset. You can reuse existing examples for repeat demonstrations.
Select an existing journey or create a new fictional showcase.
Financial snapshot · fictional USD
Advertiser charge: —
Publisher cost: —
Retained event margin: —
Subscription invoice: —
Invoice is a draft; displayed margin excludes platform subscriptions, overhead and tax.
Mobile evidence · not independently verified
Select a showcase to see reported first opens.
Android referrer is a candidate claim; iOS first-open remains unattributed. Neither can create a payable mobile installation.
Optional automatic fictional webhook trials
By default, Vexa does not transmit these postbacks. An VimoMR operator may explicitly enable VEXA_WEBHOOK_TEST_HOST and VEXA_AUTO_TEST_POSTBACKS=enabled, do not add a new Cron Trigger during the demo: the shared scheduler also processes existing publisher callbacks. Only fictional postbacks using POST to that exact approved host may be delivered. Test data in this showcase uses reserved .invalid hosts that cannot be allowlisted.
Test delivery controls are checking the Cloudflare configuration.
No outbound tests requested.
Navigate the same dataset across modules
Postback Queue
Event routing, outbox and controlled fictional webhook tests.
What is actually working?
New authenticated customer events are matched to enabled sandbox subscriptions and written to one outbox row per destination. The legacy publisher callback system is unchanged. New subscriptions never send automatically; fictional test deliveries require separate opt-in.
Staged postback rows
Enabled sandbox destinations
Authenticated-event rows
Successful fictional test sends
Run a fictional fan-out test
Create one separate outbox row for every matching subscription. Select only generated DEMO ONLY accounts. A subscription must first be saved and enabled in the Integration Center.
No test executed yet.
Recorded postback routing decisions
Not automatically deliveredDatabase-backed search · 20 rows per page.
| Event / campaign | Destination / publisher | Event | Method | Source | Status | Time (UTC) |
|---|
Controlled webhook delivery lab
Default: OFF. To enable a test, the operator must first set VEXA_WEBHOOK_TEST_HOST in Cloudflare to the exact external receiver hostname. Only fictional synthetic_test events using POST can be prepared and sent manually. No actual customer event, conversion, publisher payout or invoice is transmitted here.
Checking outbound safety gate…
Loading your server-side hostname allowlist.
| Fictional event | Receiver | Delivery status | Attempts | HTTP / Last error | Action |
|---|
Only fictional, explicitly approved HTTPS test requests can be sent.
A successful HTTP 2xx proves the receiver accepted one test request, not production readiness or cryptographic verification by the receiver. Up to five manual attempts; retry delays increase after errors.
Webhook Reliability Ledger
Independent attempt receipts, terminal failures and operator acknowledgements for fictional delivery trials. Never sends HTTP from this panel.
Durable attempt receipts
Open terminal failures
Customer records held (not sent)
Fictional sender permission
Dead-letter review
| Event / receiver | Attempts | Last error | Review state | Action |
|---|
Recent delivery attempts
| Time (UTC) | Event / receiver | Attempt | Result | HTTP / Error |
|---|
No reliability action executed. Viewing this panel never sends HTTP.
A terminal failure cannot be replayed by this screen. Any reattempt after the five-attempt limit requires a separately reviewed design. Production customer delivery remains disabled.
Authenticated Demo Event Delivery Pilot
A real customer-key authenticated Demo Journey event, independently approved for one receiver. OFF by default. No automatic requests, no commercial customers, and no payout changes.
Isolated Dispatch Infrastructure · v2.5
Separate durable queue simulation. Production delivery disabled. No outbound HTTP from this module.
Read-only overview available after sign in.
Checking signed delivery safeguards...
This panel does not transmit requests.
| Fictional API event | Receiver | Approval / job | Attempts / HTTP | Actions |
|---|
Delivery inspection
Select Inspect to run a no-write validation of a generated fictional customer event.
An operator must separately enable VEXA_DEMO_CUSTOMER_DELIVERY, approve VEXA_WEBHOOK_TEST_HOST, and set an independent VEXA_DEMO_DELIVERY_SIGNING_KEY. Approvals expire after 45 minutes. Delivery requires a separate manual confirmation. Production customer records are never eligible.
Next production gates
v2.4 adds individually authorized DEMO-only API-event delivery; v2.3 added durable fictional attempt receipts and dead-letter reviews. Recipient-side signature verification, production customer fan-out, independent scheduling, and load testing remain not implemented.
Attribution Center
Search deterministic acquisition ownership from publisher click through user and downstream CPA milestone.
What this proves
Once an authenticated user is first linked to a valid Vexa click, that customer/user attribution is fixed. Downstream survey rewards reuse the same click, campaign, publisher and sub-ID. This is deterministic CPA attribution—not independent Play/App Store install verification.
Attributed users
Approved milestone conversions
Pending milestones
Review required
Read-only attribution directory. No attribution is changed from this screen.
| User / attribution time | Campaign / model | Publisher / sub-ID | Click | Milestone progress | Conversion |
|---|
RIWI milestone CPA models
Option 1: authenticated survey rewards accumulate to $10 → one CPA conversion at the campaign payout (for example $5).
Option 2: two unique rewarded surveys → one CPA conversion at the campaign payout (for example $3).
Duplicate survey credits are blocked by survey ID. Reward reversals invalidate the credit and place any prior legacy milestone conversion into review. Publisher postbacks are staged through the existing postback system.
Mobile Measurement
Operate Android/iOS app measurement, backend credentials, lifecycle/value events, consent, deep-link recovery and attribution evidence.
Backend-authenticated mobile measurement
Use app-scoped secrets only on an advertiser-owned backend. Vexa stores only credential hashes, minimizes attribution evidence, supports deferred routing and can serve association files. Native app binaries, Play/App Store authenticity and third-party network certification remain independently validated.
App directory & integration state
Database-wide search. Activate a profile before app-scoped backend intake.
| App | Customer | Platform | Environment | Integration | Credentials | Measurements | Action |
|---|
Configure selected app
Backend request model
POST /v1/mobile/app-ingest
Authorization: Bearer APP_BACKEND_SECRET
Content-Type: application/json
{
"kind": "purchase",
"install_id": "your-stable-install-id",
"event_id": "your-idempotent-event-id",
"value_usd": 3.50,
"currency": "USD",
"consent_measurement": true
}Supported kinds: first_open, event, app_open, session_start, purchase, subscription, ad_revenue, uninstall and consent.
App-scoped backend credential
The new secret will appear once. Store it only on your backend.
| App | Label | Status | Last used | Action |
|---|
Android App Links / Apple Universal Links
Vexa can serve association metadata on a hostname routed to this Worker. OS/app signing validation remains external.
| App | Platform | Domain | Association endpoint | Updated |
|---|
| App | Type | Event | Value | Consent | Install | Occurred |
|---|
| App | Evidence | Review | Received | Action |
|---|
| Route | Platform | State | Install | Created |
|---|
Legacy lab remains below
The existing Android test app, candidate attribution simulator and evidence inspector remain available for validation. They do not create payable installs.
Test integration only
Mobile events require authenticated advertiser-backend submission. Android Play referrer claims are logged as candidates—not verified installs. iOS Apple attribution signature verification remains pending. SDK identifiers alone never earn supplier payouts.
Register app
You'll receive a public app identifier. App integration must use your advertiser backend; never put the customer API secret inside a mobile app.
SDK / attribution checklist
1. Developer integrates Android/iOS SDK starter with the app.
2. App sends first-open and consented events to its OWN backend.
3. Backend signs/authenticates and forwards events to RFR.
4. VimoMR records click-match candidates, fraud flags and review state.
5. Real payable install approval needs verified evidence and a separate acceptance test.
Android: Play Install Referrer evidence. iOS: AdAttributionKit signed postbacks require separate cryptographic validation.
| App name | Customer | Platform | Bundle/package ID | Public app ID |
|---|
| Install ID | Platform | Click ID | Evidence | Attribution status | UTC first open |
|---|
Mobile Attribution Studio
App-specific click lookback, consent control, candidate matching simulation and install evidence inspection.
Evidence is not verification
This studio cannot certify app installation or approve payouts. Android referrer data is an unverified candidate claim; iOS signed attribution verification requires a separate integration.
Per-app attribution policy
Attribution simulation — writes nothing
Select an app, then simulate. This will not insert records.
Installation evidence inspector
Select an existing first-open report. Evidence, in-app events and risk flags will appear here.
Mobile Campaign & Click Lab
One place for a DEMO Android campaign, dedicated publisher tracking link, synthetic click recording and read-only attribution preview. Never creates store-verified installs, paid conversions or postbacks. The existing Web Showcase is unchanged.
Load lab to inspect DEMO Android campaigns. No activity will be recorded until you explicitly confirm a synthetic click.
The recorded synthetic click is labelled VEXA_V29_SANDBOX in the database. It does NOT validate Google Play attribution and does not change a pre-existing unattributed first-open.
Android Event Journey
View actual first-open and in-app event records for DEMO Android apps. Operator read-only. No verified installation, payout or partner delivery.
Choose the DEMO Android Test Lab and load the journey.
First-open reports and linked event counts
| Install ID | Attribution | Linked events | First open UTC |
|---|---|---|---|
| Not loaded yet | |||
Recent in-app events
| Event | Install ID | Event ID | Occurred UTC |
|---|---|---|---|
| Not loaded yet | |||
Mobile Launch Lab · v2.6
Read-only database readiness plus deterministic synthetic decision tests. No payouts, external HTTPS or acceptance signoffs.
| Readiness requirement | Status | Reason |
|---|---|---|
| Not inspected yet | ||
Read-only integrity
No check performed yet.
Deterministic test cases
| Case | Result | Observed |
|---|---|---|
| No synthetic tests yet | ||
To connect a real test app, use the Android/iOS developer starter and an advertiser-owned backend. Never place a server API key in an app binary.
Deep Links & Routing
Create searchable customer-scoped mobile routes, choose Android/iOS destinations and test deterministic fallbacks.
What this module proves
Vexa can select a platform-specific destination, validate an optional Vexa click against the campaign, preserve the click ID and fall back to HTTPS. This does not certify Android App Links, Apple Universal Links, store install attribution or production domain association.
Create / edit mobile deep link
No route saved in this session.
Read-only route simulator
Choose a route and platform. The simulator does not increment hits or follow the destination.
| Route | Campaign | Apps | Status | Hits | Action |
|---|
Fraud & Traffic Quality
First-party traffic scoring, Monitor/Enforce policies, blocklists, case review and mobile quality evidence.
Deterministic first-party quality controls
Monitor records evidence without blocking. Enforce rejects only clicks with a block disposition. Historical scans never block past traffic, and case decisions never reverse payouts automatically.
Campaign fraud policy
Start in Monitor and inspect live decisions before enabling enforcement.
No policy action in this session.
Publisher / sub-affiliate blocklists
Entries may be global or campaign-specific. Matches are hard-block dispositions but reject traffic only when the campaign policy is Enforce.
| Scope | Type | Value | Reason | Status | Action |
|---|
Case queue
Operator resolution is audited and does not automatically modify finance.
| Case | Campaign | Publisher | Score | Severity | Summary | Status | Action |
|---|
| UTC | Campaign | Publisher | Sub-ID | Score | Disposition | Mode | Reasons |
|---|
| UTC | App | Customer | Reason | Status |
|---|
Capability Acceptance Register
Documented feature-level QA against the full product roadmap.
What counts as Completed?
A feature must have documented acceptance evidence and a recorded operator sign-off. Installed D1 tables, demo data and source-code presence do not count. The historical baseline comes from an older code audit and is not a current feature-verification score.
Roadmap capabilities
QA accepted with evidence
Not yet accepted
Documented acceptance coverage
Choose capability and record an acceptance test
| Capability | Module | Old audit | Acceptance | Action |
|---|
Acceptance documents operator QA only. Store verification, security review, legal/compliance and production load tests must still be performed independently.
Platform Map
All 16 product modules in one architecture, with honest implementation status.
A module may be present in the architecture without having completed production validation. Each card lists its verified scope and missing functionality.
Unified execution model
Advertiser → Campaign → Publisher click/sub-ID → deterministic user attribution → authenticated downstream events → automatic/manual CPA milestone → payout ledger → reporting → publisher postbacks. Independent app-store install verification remains a separate Mobile Measurement gate.
Report Studio
Arrange rows, columns, and metrics to build live event-based pivot reports.
Events only: clicks without events are not included. No advertiser revenue, installs or attribution outcomes are fabricated.
Available dimensions
Click to add to Rows or drag into a zone.
Rows drag to reorder
Columns drag to reorder
Values / metrics
Trace an event or click
Exact identifier lookup for debugging event intake and attribution, without exposing private keys.