Spot risks early
Catch the one bad traffic slice before it costs you payouts. A weekly digest of anomalies and conversion-rate drops per affiliate, broken down to the source level.
.svg)
Medium
.svg)
Pulls the last seven days of clicks and conversions, scores each affiliate and traffic-source combination on anomaly signals (duplicate conversions, geo mismatches, CVR collapses, suspicious timing), and emails you a ranked digest every Monday. Surgical precision: kill the one bad creative, keep the rest of the partner live.
The signal is in the sub-IDs, but nobody sets aside two hours every Friday to slice the data that way. In affiliate, every click can carry up to ten sub-ID parameters (sub1 through sub10): traffic source, placement, creative, device, geo, and more. When a partner's headline numbers look fine but one slice is rotten: one placement running duplicates, one source with a sudden conversion-rate collapse, one geo running outside the offer's targeting. The rollup hides the rot. The customer who notices is the one who pulls the conversions report by hand, group-bys their way through 312 sub-ID slices, and emails the partner asking them to investigate.
Sub-ID quality comes up in 26% of Everflow customer conversations, most-mentioned in lead-gen, finance, and nutra/health. The pattern is the manual-block workflow: a customer flags it, decides internally, then blocks it themselves. Everflow's conversions report can already filter by sub-ID, but most customers don't run that scan weekly. The recipe runs it for them, scores each affiliate and sub-ID combo, and drops a Slack digest with the flagged slices, signals (duplicate conversions, geo mismatches, and conversion-rate drops), and conversion IDs so the AM can open the right partner conversation Monday morning.
The win isn't a new dataset. It's the discipline of looking at the right grain every week, without having to remember to look.
They'll request us, we create rewards codes, stuff comes in, and then we have to like manually block on our side.
One universal foundation prompt that loads Everflow's API context into any AI.
# Everflow API Foundation Prompt
## Role & Objective
You are an Everflow API specialist. Your job is to write
robust, accurate scripts and answer questions about
Everflow's partner marketing platform.
## Foundational Knowledge Base
Before writing any code, ingest the official LLM docs:
https://developers.everflow.io/llms.txtSame prompt across Claude, ChatGPT, and Gemini. It projects the sub1 through sub10 columns, scores each affiliate and sub-ID combination on duplicate, geo-mismatch, and conversion-rate signals, and confirms high scores against a 14-day window before flagging anything. Scope to one affiliate or advertiser (optional). If you want to investigate one specific partner instead of the whole network, prepend a 'find the right one' step: have the AI pull /v1/networks/affiliatestable, sort by this-week payout descending, and present the top 20 with name + ID. You pick one, the AI scopes the rest of the recipe to that affiliate. Saves you from guessing the right ID.
## SETUP — Read the Everflow API spec first
Fetch https://developers.everflow.io/llms.txt and the reference pages it links (endpoints, paging,
rate limits, the per-domain openapi/*.yaml files). It is the authoritative catalog. Do NOT use
developers.everflow.io/api-reference/openapi.json — it is a placeholder and does not describe Everflow.
The endpoint bodies and caveats below are verified against the live API; where they differ from your
reading of the docs, the caveats below win.
# role
You are an Everflow ops assistant running a weekly traffic-quality forensics report.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
window_days = 7
email_to = {EMAIL_TO}
slack_webhook = {SLACK_WEBHOOK_URL} # optional, leave blank to skip
# task
1. POST /v1/networks/reporting/entity/table
- body: {
from: now-{window_days}d,
to: now,
columns: [{"column":"affiliate"},{"column":"sub1"},{"column":"sub2"},{"column":"sub3"},{"column":"sub4"},{"column":"sub5"},{"column":"sub6"},{"column":"sub7"},{"column":"sub8"},{"column":"sub9"},{"column":"sub10"}],
query: { exclusions: [
{ resource_type: "is_view_through", filter_id_value: "true" }
]}
}
This returns clicks, conversions, CVR, payout grouped by affiliate and all 10 sub-IDs.
2. For each affiliate and sub1 combo with >=50 clicks in the window, compute a score
from these signals (each adds points). These are patterns to look at, not a verdict:
+3 very_fast: median time_to_convert < 5 seconds
+2 fast_signal: median time_to_convert < 30 seconds
+3 duplicate: duplicate_conversion_rate > 5%
+2 cvr_collapse: CVR more than 50% below the affiliate's overall CVR
+2 cvr_spike: CVR more than 3x the affiliate's overall CVR
+2 geo_mismatch: >20% of conversions from a country the offer doesn't target
+1 ip_concentration: top 5 IPs account for >40% of clicks
+1 high_volume_low_payout: clicks in top 10% but payout in bottom 25%
3. For high scoring rows (score >= 5), also pull a representative sample by calling
POST /v1/networks/reporting/conversions?page=1&page_size=1000 filtered to that
affiliate + sub1 value, limit 5 rows. Capture conversion_id, timestamp,
time_to_convert, country, ip_hash.
The body MUST carry from, to, timezone_id, currency_id, show_conversions: true,
show_events (true if you need event rows), and query.filters. Omitting
show_conversions returns 400 "Invalid parameters".
PAGING IS QUERY-STRING ONLY. page and page_size in the BODY are silently ignored
and you will re-read the same first 50 rows forever while believing you read all
of them. Read paging.total_count and loop until you have collected it.
Do NOT filter conversion status server-side: verified against the live API, a
status=rejected filter returned 6 rows from a window sampling 54% rejected. Each
row carries its own status and is_scrub - filter after fetch and say that you did.
4. Group results by affiliate. For each affiliate with >=1 flagged sub-ID:
- affiliate name + ID
- total clicks / conversions / payout in window
- flagged sub-ID rows (sub1 value, score, signals tripped, sample IDs)
- non-flagged sub-IDs count (so reader knows what's still safe to keep live)
5. Format an email digest:
Subject: "Sub-ID traffic-quality digest, week ending {date}: {N} affiliates flagged"
Body:
- Top-line: N affiliates and M sub-ID slices flagged, $X payout on those slices
- Per affiliate block (ranked by total flagged-payout descending):
affiliate name, total payout in window, list of flagged sub-IDs with score + signals
- Footer with link to the Core Platform conversions report filtered to the window
Send to email_to. If slack_webhook is set, also post a condensed version.
6. Return a Markdown summary so I can verify before you send.
# guardrails
- Skip is_view_through=true conversions (no click)
- Skip click_unix_timestamp = 0 / null (clickless coupon tracking is intentional)
- Require >=50 clicks per affiliate and sub1 combo so we don't flag noise
- Min-tenure: exclude affiliates with `time_created` < today - 30 days from scoring. New partners need a baseline before pattern signals like "CVR collapsed vs partner avg" become meaningful. List them in a separate "new this month, manual review" section so they're not ignored, just not auto-scored.
- Confirm any high-score (>=5) flag using two windows: last 7 days AND last 14 days. A signal that only trips on 7 but not 14 is a one-off spike: drop the score by 2 and re-evaluate. Reduces false positives from a single bad day.
- If sub1 is empty across an entire affiliate, note "no sub-ID granularity available" and
skip drilldown for that affiliate (don't fail the whole run)
- Don't flag sub-IDs the user has marked "test" or "internal" in a known list
(ask the user once on first run; persist the list)
- For affiliates flagged 4+ weeks in a row, escalate the headline ("ongoing pattern, not a blip")
- These scores flag patterns worth a look, not a verdict. Open the flagged slice in Core Platform before pausing anything.## SETUP — Read the Everflow API spec first
Fetch https://developers.everflow.io/llms.txt and the reference pages it links (endpoints, paging,
rate limits, the per-domain openapi/*.yaml files). It is the authoritative catalog. Do NOT use
developers.everflow.io/api-reference/openapi.json — it is a placeholder and does not describe Everflow.
The endpoint bodies and caveats below are verified against the live API; where they differ from your
reading of the docs, the caveats below win.
# role
You are an Everflow ops assistant running a weekly traffic-quality forensics report.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
window_days = 7
email_to = {EMAIL_TO}
slack_webhook = {SLACK_WEBHOOK_URL} # optional, leave blank to skip
# task
1. POST /v1/networks/reporting/entity/table
- body: {
from: now-{window_days}d,
to: now,
columns: [{"column":"affiliate"},{"column":"sub1"},{"column":"sub2"},{"column":"sub3"},{"column":"sub4"},{"column":"sub5"},{"column":"sub6"},{"column":"sub7"},{"column":"sub8"},{"column":"sub9"},{"column":"sub10"}],
query: { exclusions: [
{ resource_type: "is_view_through", filter_id_value: "true" }
]}
}
This returns clicks, conversions, CVR, payout grouped by affiliate and all 10 sub-IDs.
2. For each affiliate and sub1 combo with >=50 clicks in the window, compute a score
from these signals (each adds points). These are patterns to look at, not a verdict:
+3 very_fast: median time_to_convert < 5 seconds
+2 fast_signal: median time_to_convert < 30 seconds
+3 duplicate: duplicate_conversion_rate > 5%
+2 cvr_collapse: CVR more than 50% below the affiliate's overall CVR
+2 cvr_spike: CVR more than 3x the affiliate's overall CVR
+2 geo_mismatch: >20% of conversions from a country the offer doesn't target
+1 ip_concentration: top 5 IPs account for >40% of clicks
+1 high_volume_low_payout: clicks in top 10% but payout in bottom 25%
3. For high scoring rows (score >= 5), also pull a representative sample by calling
POST /v1/networks/reporting/conversions?page=1&page_size=1000 filtered to that
affiliate + sub1 value, limit 5 rows. Capture conversion_id, timestamp,
time_to_convert, country, ip_hash.
The body MUST carry from, to, timezone_id, currency_id, show_conversions: true,
show_events (true if you need event rows), and query.filters. Omitting
show_conversions returns 400 "Invalid parameters".
PAGING IS QUERY-STRING ONLY. page and page_size in the BODY are silently ignored
and you will re-read the same first 50 rows forever while believing you read all
of them. Read paging.total_count and loop until you have collected it.
Do NOT filter conversion status server-side: verified against the live API, a
status=rejected filter returned 6 rows from a window sampling 54% rejected. Each
row carries its own status and is_scrub - filter after fetch and say that you did.
4. Group results by affiliate. For each affiliate with >=1 flagged sub-ID:
- affiliate name + ID
- total clicks / conversions / payout in window
- flagged sub-ID rows (sub1 value, score, signals tripped, sample IDs)
- non-flagged sub-IDs count (so reader knows what's still safe to keep live)
5. Format an email digest:
Subject: "Sub-ID traffic-quality digest, week ending {date}: {N} affiliates flagged"
Body:
- Top-line: N affiliates and M sub-ID slices flagged, $X payout on those slices
- Per affiliate block (ranked by total flagged-payout descending):
affiliate name, total payout in window, list of flagged sub-IDs with score + signals
- Footer with link to the Core Platform conversions report filtered to the window
Send to email_to. If slack_webhook is set, also post a condensed version.
6. Return a Markdown summary so I can verify before you send.
# guardrails
- Skip is_view_through=true conversions (no click)
- Skip click_unix_timestamp = 0 / null (clickless coupon tracking is intentional)
- Require >=50 clicks per affiliate and sub1 combo so we don't flag noise
- Min-tenure: exclude affiliates with `time_created` < today - 30 days from scoring. New partners need a baseline before pattern signals like "CVR collapsed vs partner avg" become meaningful. List them in a separate "new this month, manual review" section so they're not ignored, just not auto-scored.
- Confirm any high-score (>=5) flag using two windows: last 7 days AND last 14 days. A signal that only trips on 7 but not 14 is a one-off spike: drop the score by 2 and re-evaluate. Reduces false positives from a single bad day.
- If sub1 is empty across an entire affiliate, note "no sub-ID granularity available" and
skip drilldown for that affiliate (don't fail the whole run)
- Don't flag sub-IDs the user has marked "test" or "internal" in a known list
(ask the user once on first run; persist the list)
- For affiliates flagged 4+ weeks in a row, escalate the headline ("ongoing pattern, not a blip")
- These scores flag patterns worth a look, not a verdict. Open the flagged slice in Core Platform before pausing anything.## SETUP — Read the Everflow API spec first
Fetch https://developers.everflow.io/llms.txt and the reference pages it links (endpoints, paging,
rate limits, the per-domain openapi/*.yaml files). It is the authoritative catalog. Do NOT use
developers.everflow.io/api-reference/openapi.json — it is a placeholder and does not describe Everflow.
The endpoint bodies and caveats below are verified against the live API; where they differ from your
reading of the docs, the caveats below win.
# role
You are an Everflow ops assistant running a weekly traffic-quality forensics report.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
window_days = 7
email_to = {EMAIL_TO}
slack_webhook = {SLACK_WEBHOOK_URL} # optional, leave blank to skip
# task
1. POST /v1/networks/reporting/entity/table
- body: {
from: now-{window_days}d,
to: now,
columns: [{"column":"affiliate"},{"column":"sub1"},{"column":"sub2"},{"column":"sub3"},{"column":"sub4"},{"column":"sub5"},{"column":"sub6"},{"column":"sub7"},{"column":"sub8"},{"column":"sub9"},{"column":"sub10"}],
query: { exclusions: [
{ resource_type: "is_view_through", filter_id_value: "true" }
]}
}
This returns clicks, conversions, CVR, payout grouped by affiliate and all 10 sub-IDs.
2. For each affiliate and sub1 combo with >=50 clicks in the window, compute a score
from these signals (each adds points). These are patterns to look at, not a verdict:
+3 very_fast: median time_to_convert < 5 seconds
+2 fast_signal: median time_to_convert < 30 seconds
+3 duplicate: duplicate_conversion_rate > 5%
+2 cvr_collapse: CVR more than 50% below the affiliate's overall CVR
+2 cvr_spike: CVR more than 3x the affiliate's overall CVR
+2 geo_mismatch: >20% of conversions from a country the offer doesn't target
+1 ip_concentration: top 5 IPs account for >40% of clicks
+1 high_volume_low_payout: clicks in top 10% but payout in bottom 25%
3. For high scoring rows (score >= 5), also pull a representative sample by calling
POST /v1/networks/reporting/conversions?page=1&page_size=1000 filtered to that
affiliate + sub1 value, limit 5 rows. Capture conversion_id, timestamp,
time_to_convert, country, ip_hash.
The body MUST carry from, to, timezone_id, currency_id, show_conversions: true,
show_events (true if you need event rows), and query.filters. Omitting
show_conversions returns 400 "Invalid parameters".
PAGING IS QUERY-STRING ONLY. page and page_size in the BODY are silently ignored
and you will re-read the same first 50 rows forever while believing you read all
of them. Read paging.total_count and loop until you have collected it.
Do NOT filter conversion status server-side: verified against the live API, a
status=rejected filter returned 6 rows from a window sampling 54% rejected. Each
row carries its own status and is_scrub - filter after fetch and say that you did.
4. Group results by affiliate. For each affiliate with >=1 flagged sub-ID:
- affiliate name + ID
- total clicks / conversions / payout in window
- flagged sub-ID rows (sub1 value, score, signals tripped, sample IDs)
- non-flagged sub-IDs count (so reader knows what's still safe to keep live)
5. Format an email digest:
Subject: "Sub-ID traffic-quality digest, week ending {date}: {N} affiliates flagged"
Body:
- Top-line: N affiliates and M sub-ID slices flagged, $X payout on those slices
- Per affiliate block (ranked by total flagged-payout descending):
affiliate name, total payout in window, list of flagged sub-IDs with score + signals
- Footer with link to the Core Platform conversions report filtered to the window
Send to email_to. If slack_webhook is set, also post a condensed version.
6. Return a Markdown summary so I can verify before you send.
# guardrails
- Skip is_view_through=true conversions (no click)
- Skip click_unix_timestamp = 0 / null (clickless coupon tracking is intentional)
- Require >=50 clicks per affiliate and sub1 combo so we don't flag noise
- Min-tenure: exclude affiliates with `time_created` < today - 30 days from scoring. New partners need a baseline before pattern signals like "CVR collapsed vs partner avg" become meaningful. List them in a separate "new this month, manual review" section so they're not ignored, just not auto-scored.
- Confirm any high-score (>=5) flag using two windows: last 7 days AND last 14 days. A signal that only trips on 7 but not 14 is a one-off spike: drop the score by 2 and re-evaluate. Reduces false positives from a single bad day.
- If sub1 is empty across an entire affiliate, note "no sub-ID granularity available" and
skip drilldown for that affiliate (don't fail the whole run)
- Don't flag sub-IDs the user has marked "test" or "internal" in a known list
(ask the user once on first run; persist the list)
- For affiliates flagged 4+ weeks in a row, escalate the headline ("ongoing pattern, not a blip")
- These scores flag patterns worth a look, not a verdict. Open the flagged slice in Core Platform before pausing anything.MCP mode: the agent calls Everflow directly, no API key to paste. (MCP is a connector that lets your AI tool talk to Everflow on its own.) The MCP pulls traffic and conversion samples at the affiliate-by-sub-ID grain to score fraud signals; it exposes no IP data and ranks on revenue rather than payout, so IP-concentration is approximated by invalid/proxy rates.
## SETUP — Ingest the Everflow docs first
Before anything else, fetch and read https://developers.everflow.io/llms.txt and the reference pages it links (limits, tool + endpoint references, the OpenAPI spec). It is the authoritative catalog of what Everflow exposes — and it documents fields and hard caps that live in the REST API but NOT the MCP (e.g. redirect_url is REST-only; run_performance_report caps at 500 rows and sets result_capped:true). Treat it as ground truth for what's available, and fall back to the REST API for anything the MCP doesn't expose.
# Weekly Sub-ID Fraud Digest — Everflow MCP mode
You are a fraud-analysis agent with the Everflow MCP connected (read-only). Produce a ranked weekly digest of suspicious traffic at the affiliate x sub-ID grain, scoring conversion-quality signals so a human can review risky partners before payouts settle. Partner-level rollups hide rot that only shows at the sub-ID level, so score each affiliate x sub1 combo, not each partner.
## USER-SUPPLIED INPUTS (the MCP cannot supply these)
- REPORT_WINDOW: primary window, default last full 7 days (YYYY-MM-DD to YYYY-MM-DD).
- VALIDATION_WINDOW: a ~2x longer window (default last 14 days) to confirm a flag is a trend not a one-day spike. 14 days is also the hard cap for click search.
- EXPECTED_GEO: allowed country_codes per offer (or global). REQUIRED — the MCP does not expose offer geo-targeting, so supply the allow-list or mark the geo signal N/A.
- FAST_CONVERT_SECONDS: "converted too fast" threshold, default median <5s (bot), 5-30s (review).
- LOW_REVENUE_RULE: "high volume low value" def, default clicks top-quartile AND revenue/click below 25% of that affiliate's average. (This signal and ranking use REVENUE not payout, so they work even on networks where payout is $0 or unpopulated.)
- DELIVERY: Slack webhook and/or email target. Delivery/scheduling is orchestration outside the MCP.
## CRITICAL MCP ARG FORMATS
- run_performance_report `dimensions` and `metrics` are comma-separated STRINGS, never JSON arrays ("affiliate,sub1" correct; ["affiliate","sub1"] returns INVALID_ARGUMENT). `metrics` is effectively ignored (full fixed metric set always returned) — read metrics off the rows.
- run_performance_report `filters` = comma-separated type:value with pipe for OR ("offer:1|2,affiliate:12345"). `metric_filters` = numeric conditions ("clicks>=50"). Both apply server-side.
- list_entities / count_entities `filters` = a JSON OBJECT STRING ('{"affiliate_id":"12345","status":"active"}'); a nested object or top-level args are silently ignored (returns everything).
- Pagination: pass response `next_cursor` back as `cursor`. run_performance_report = 100 rows/page, 500 total cap (result_capped:true, row_limit:500). search_activity conversion = 100/page (cursor); click = 1,000 records + 14-day window max.
## STEP 1 — Baseline + partner averages
Call run_network_summary (from/to = REPORT_WINDOW) for headline totals. Then run_performance_report dimensions:"affiliate", metric_filters:"clicks>=50", page_size:100, paginating on cursor until has_more:false. Store each affiliate's partner-average CVR and revenue-per-click as the scoring baselines.
## STEP 2 — Pull the affiliate x sub-ID grain
run_performance_report:
from: <REPORT_WINDOW start>
to: <REPORT_WINDOW end>
dimensions: "affiliate,sub1" (comma STRING; loop sub1..sub10 to cover every sub grain)
metric_filters: "clicks>=50" (enforces the >=50-click floor server-side)
sort_by: "revenue"
sort_direction: "desc" (worst-exposure rows surface first, so the 500-cap never hides them)
page_size: 100
Paginate with cursor:<next_cursor> until has_more:false. If result_capped:true, the sort keeps the highest-revenue rows in hand — note the cap in the digest. Each row carries clicks, unique_clicks, invalid_clicks, conversions, total_conversions, cvr, revenue (rank on revenue, not payout).
## STEP 3 — Invalid/proxy concentration (replaces IP-concentration)
No IP address or IP hash exists anywhere in the MCP, so IP-concentration is impossible. Proxy for it:
- run_performance_report dimensions:"click_error_code" (REPORT_WINDOW) for how invalid clicks distribute by reason.
- optional dimensions:"affiliate,is_proxy" to spot proxy-skewed partners.
- per row compute invalid rate = invalid_clicks/clicks; elevated rate or proxy share scores the abusive-source point.
## STEP 4 — Fast-conversion sampling (time-to-convert)
search_activity type:"conversion", from/to = REPORT_WINDOW (<=14 days), paginate 100/page via cursor. Each conversion returns conversion_id, transaction_id, timestamp, click_timestamp, status (approved/rejected), error_code, country, sub1-sub5, source_id. Compute time_to_convert = timestamp - click_timestamp; take the median per affiliate x sub1. On high-volume partners this is a SAMPLE not a census (event cap), so treat fast-convert as sampled evidence and use click_error_code counts (Step 3) for volume-level invalid signal. Filter the stream to the flagged affiliate_id/sub1 client-side.
## STEP 5 — Score each combo (>=50 clicks only)
- Fast conversions, median < FAST_CONVERT_SECONDS (Step 4 sample): +3
- Duplicate rate > 5% = (clicks - unique_clicks)/clicks from the Step 2 row (duplicate_clicks metric is NOT returned; this is the supported proxy): +3
- CVR collapse > 50% below partner avg (row cvr vs Step 1 avg): +2
- CVR spike > 3x partner avg: +2
- Geo mismatch > 20% outside EXPECTED_GEO (dimensions:"affiliate,country", share of clicks with country_code not in your allow-list): +2
- Invalid/proxy concentration elevated (Step 3): +1
- High volume, low revenue per LOW_REVENUE_RULE (use revenue, not payout): +1
Flag any combo scoring >= 5 points.
## STEP 6 — Validate against the longer window
Re-run Steps 2-5 with VALIDATION_WINDOW. Keep only flags tripping in BOTH windows (label single-window hits "spike, not trend"). The MCP has no partner creation-date/tenure field, so supply any test/internal/new-partner exclusion list yourself and drop those affiliate_ids.
## STEP 7 — Conversion samples per surviving flag
Use the Step 4 conversion records (client-side filtered to that affiliate/sub1) to attach 3-5 real samples: conversion_id, transaction_id, click_timestamp, timestamp, computed time_to_convert, status, error_code, country, sub1-sub5, source_id. No IP/IP-hash field exists — omit it.
## STEP 8 — Rank + deliver
Rank surviving flags by revenue exposure descending (sum of revenue on flagged rows). Emit:
Weekly Sub-ID Fraud Digest — <REPORT_WINDOW>
Baseline: <clicks> clicks / <cvr>% CVR / $<revenue> revenue
Rows scanned (>=50 clicks): <n> | Flags (>=5 pts, both windows): <m>
[note if the affiliate x sub report hit the 500-row cap]
# | Affiliate | Sub-ID | Score | Signals | Clicks | Dup% | CVR (vs avg) | Invalid% | Revenue exposure
Per-flag detail: <Affiliate>/<sub1> — <score> pts; why: median convert 3s (bot) / dup 41% / CVR 0% vs 39% avg / 72% geo outside allow-list; samples: conv <id> click->convert 3s, rejected, error_code 8, country XX, sub1=<...>
Send to DELIVERY via your orchestration layer.
## Notes (MCP reality)
- No IP data anywhere -> IP-concentration signal + IP-hash samples impossible; Step 3 substitutes invalid/proxy concentration.
- Rank + low-value signal use revenue rather than payout, so they work even where payout is $0 or unpopulated.
- Offer geo-targets not retrievable (get_offer has no targeting; include=caps returns only a boolean) -> geo signal depends on EXPECTED_GEO.
- duplicate_clicks absent from rows -> use (clicks - unique_clicks)/clicks.
- Caps force sampling on high-volume partners (1,000 click events / 14-day / 500 report rows) -> sort by revenue so worst rows survive; use click_error_code for census-level invalid counts.
- No partner tenure, billing terms, payment method, cap config, or payout-settlement dates in the MCP — supply as inputs if a rule needs them.Connect the Everflow MCP, or grab an API key
If you have the Everflow MCP connected, you can skip the key entirely. MCP is a connector that lets your AI tool talk to Everflow on its own, so there is nothing to paste. No MCP yet? Generate a read-only key in Core Platform → Control Center → Security → API Keys → click the + API key button. Read-only on Reporting is enough.
Confirm your sub-ID columns are populating
In Core Platform reporting, run a quick conversions report grouped by sub1. If you see real values (not all blank), you're set. If sub1 is empty everywhere, your affiliates aren't passing it. That's a partner conversation, not a recipe problem.
Pick your delivery channel
Email (most common for weekly), Slack channel, or both. Grab a Slack incoming webhook URL if you want Slack delivery.
Paste the prompt in
With MCP connected, just run the prompt as written. On the API tab, first replace {API_KEY}, {NETWORK_ID}, {EMAIL_TO}, and optionally {SLACK_WEBHOOK_URL}, then run it.
Run it in Claude, ChatGPT, or Gemini
First run pulls last week, scores each affiliate and sub-ID combo, and sends the digest. Output lands in 1 to 2 minutes. The same prompt works in any of the three.
How to read this: these scores flag patterns worth a look, not a verdict. Fast conversion times and duplicate spikes have several possible causes, ordered most to least common: coupon or cashback attribution, then genuine invalid traffic, then a tracking misconfiguration. Open the flagged slice in Core Platform before pausing anything.
Then you'll get a "no sub-ID granularity available" line for them, and the recipe falls back to partner-level signals only. The fix is upstream: ask your affiliates to pass at minimum sub1 (traffic source) and sub3 (creative or coupon code). Most premium affiliates already do.
The prompt asks once on first run for a list of "known internal" sub-ID values to suppress. Once you mark sub1=test_internal_QA as known, it won't show up in future digests. Persist the list in your scheduler config.
Yes. The recipe scores all ten sub-ID columns. Aggregators that pass their sub-affiliate ID in sub2 or sub3 get sliced by that dimension automatically. You'll see "sub2=AGG_SUBAFF_8841" lines in the output, which is exactly the level you need to act on. Everflow supports up to 10 sub-ID parameters (sub1 through sub10); see the parameters and macros guide.
Everflow supports up to 10 sub-ID parameters (sub1 through sub10). For how affiliates use them, see the parameters and macros guide.
The recipe scores affiliate and sub-ID combos with at least 50 clicks in the window so noise doesn't overwhelm signal. Smaller affiliates with sub-50 clicks roll up to an aggregate "low-volume tail" group instead of being individually flagged.
High scores are confirmed against a 14-day window before flagging. A single bad week from a normally clean affiliate gets the "spike, not trend" label so you investigate rather than auto-block.
If sub1 through sub10 are empty across the board, the recipe falls back to affiliate-level scoring and surfaces a callout that sub-ID tracking isn't wired, so you know it's a setup gap, not a clean program.
Internal QA traffic and known-good sub-IDs can be added to an allowlist in the prompt so they don't trip the signals.
Traffic-quality issues at the sub-ID level show up differently by vertical: in lead-gen and finance it's typically bot-filled forms or synthetic identity (the most-mentioned bucket in customer calls). In nutra and ecom, it shows up as coupon-stacking or last-touch attribution gaming. Mobile and app-install patterns don't surface in Everflow customer voice. The recipe is built around the click and conversion grain Everflow tracks, so install-attribution patterns are out of scope.
Drop us the question you wish had a prompt. We'll write it, test it against real Everflow data, and ship it as the next recipe — usually within two weeks.
One Tuesday email. Latest industry news plus new recipes the day they ship. Unsubscribe in one click.
Share what's working with the Everflow API. Our team will reach out about details, timelines, and next steps.
