Audit partners
Stop losing revenue to partners who quietly go dark. Get a clean reactivation list, with false positives already filtered out, delivered to your inbox every week.
Pulls every active partner with zero clicks and zero conversions in the last 30 days, filters out the false positives (paused, brand-new, seasonal, low-volume-but-high-quality), and emails you a clean list grouped by reactivation priority. Runs on a weekly schedule.
Every affiliate program has a long tail of partners who stopped sending traffic months ago and never got cleaned up. They sit in the partner list, look "approved," and quietly distort every average: your active-partner CVR, your per-partner payout, your "We have 800 partners" number on the sales deck. The fix is the same workflow at every company: open Reporting, filter to last 30 days, scroll for affiliates with zero clicks, decide one by one whether to reactivate, pause, or offboard. Hours of work, nobody's job, gets pushed to next quarter.
It comes up in roughly 1 in 5 customer conversations, the biggest partner-ops pain. The Everflow Reporting page can filter by zero-click partners, but the manual scrub (which is dormant intentionally vs needs outreach vs should be offboarded) is what nobody has 90 minutes for on a Wednesday. The recipe pulls every active partner with zero activity in the last 30 days, filters out the false positives (paused on purpose, brand-new, seasonal, low-volume-but-high-quality), and emails a clean reactivation/offboard list grouped by recommended action.
The workflow Everflow's own solutions engineers walk customers through on demos: "They haven't sent us any traffic in 30 days, we're going to deactivate them…" That’s exactly what this recipe automates. Same logic, runs weekly, surfaces the list before anyone has to remember to look.
Trying to activate and re-engage dormant affiliates… currently, we're not able to segment out based off of that activity. Do you have something like that?
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. Pulls every active partner with zero clicks/conversions in the window, then filters out paused, brand-new (under 30 days), and seasonal-pattern partners before tiering the rest by reactivation priority.
# role
You are an Everflow ops assistant.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
days = {DAYS} # default 30
new_partner_days = {NEW_PARTNER_DAYS} # default 30
seasonal_lookback = 365 # for spotting Q4-only partners
min_lifetime_value = 500 # USD, partners under this = "low value"
# task
1. POST /v1/networks/affiliatestable
- body: { filters: { account_status: ["active"] } }
- returns the full active partner roster with affiliate_id + name +
network_affiliate_id + time_created
2. POST /v1/networks/reporting/entity
- body: { from: today - {days}, to: today,
columns: [{column: "affiliate"}],
query: {} }
- returns clicks + conversions per active partner over the window
3. Cross-reference: any partner from step 1 NOT in step 2's results,
OR present with clicks=0 AND conversions=0, is a dormancy candidate.
4. Apply false-positive filters. Exclude a partner if ANY are true:
- time_created < today - {new_partner_days}d (too new)
- account_status != "active" (paused or archived intentionally)
- they had clicks or conversions in the prior {days}d window before this one
(intermittent activity, not dormant)
5. Score remaining partners by reactivation priority. For each, also pull
their lifetime stats:
- POST /v1/networks/reporting/entity with from = time_created,
to = today, columns: [{column: "affiliate"}]
Tier them:
- tier_high = lifetime conversions >= 50 OR lifetime payout >= 5000
- tier_watch = lifetime conversions 5-49 OR lifetime payout 500-4999
- tier_offboard = lifetime conversions < 5 AND lifetime payout < 500
6. For seasonal detection, check the same partner's activity in the
same window one year ago (today - 365d to today - 365d + {days}d).
If they had >0 clicks then but 0 now, tag them "seasonal_check" and
move to tier_watch regardless of lifetime score.
7. Format an email digest grouped by tier. For each partner show:
- name, network_affiliate_id, days_since_last_click, lifetime_payout,
lifetime_conversions, account_manager (if available), seasonal_check tag
- link to the partner's page in Core Platform
8. Return Markdown summary so I can verify counts before sending.
# guardrails
- Do not include partners with account_status = "paused" or "rejected".
- Min-tenure: exclude partners with `time_created` < today - {new_partner_days} days (default 30). New partners haven't been on long enough to confirm dormancy, they're still in onboarding. Default 30d; tighten to 14d for mobile, loosen to 60d for e-com with longer ramp-up.
- Confirm any "dormant" verdict using two windows: last {days} days AND last {days}*2 days. A partner who shows dormant on the short window but had activity in the longer window is intermittent, not dormant: drop to tier_watch instead of tier_offboard.
- Do not double-count partners who appear in both step 1 and step 2 with
zero activity (they're the same row).
- If a partner has no clicks but has conversions (server-postback only),
they are NOT dormant. Skip them.
- Cap email digest at top 50 per tier. Larger lists overwhelm the AM.# role
You are an Everflow ops assistant.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
days = {DAYS} # default 30
new_partner_days = {NEW_PARTNER_DAYS} # default 30
seasonal_lookback = 365 # for spotting Q4-only partners
min_lifetime_value = 500 # USD, partners under this = "low value"
# task
1. POST /v1/networks/affiliatestable
- body: { filters: { account_status: ["active"] } }
- returns the full active partner roster with affiliate_id + name +
network_affiliate_id + time_created
2. POST /v1/networks/reporting/entity
- body: { from: today - {days}, to: today,
columns: [{column: "affiliate"}],
query: {} }
- returns clicks + conversions per active partner over the window
3. Cross-reference: any partner from step 1 NOT in step 2's results,
OR present with clicks=0 AND conversions=0, is a dormancy candidate.
4. Apply false-positive filters. Exclude a partner if ANY are true:
- time_created < today - {new_partner_days}d (too new)
- account_status != "active" (paused or archived intentionally)
- they had clicks or conversions in the prior {days}d window before this one
(intermittent activity, not dormant)
5. Score remaining partners by reactivation priority. For each, also pull
their lifetime stats:
- POST /v1/networks/reporting/entity with from = time_created,
to = today, columns: [{column: "affiliate"}]
Tier them:
- tier_high = lifetime conversions >= 50 OR lifetime payout >= 5000
- tier_watch = lifetime conversions 5-49 OR lifetime payout 500-4999
- tier_offboard = lifetime conversions < 5 AND lifetime payout < 500
6. For seasonal detection, check the same partner's activity in the
same window one year ago (today - 365d to today - 365d + {days}d).
If they had >0 clicks then but 0 now, tag them "seasonal_check" and
move to tier_watch regardless of lifetime score.
7. Format an email digest grouped by tier. For each partner show:
- name, network_affiliate_id, days_since_last_click, lifetime_payout,
lifetime_conversions, account_manager (if available), seasonal_check tag
- link to the partner's page in Core Platform
8. Return Markdown summary so I can verify counts before sending.
# guardrails
- Do not include partners with account_status = "paused" or "rejected".
- Min-tenure: exclude partners with `time_created` < today - {new_partner_days} days (default 30). New partners haven't been on long enough to confirm dormancy, they're still in onboarding. Default 30d; tighten to 14d for mobile, loosen to 60d for e-com with longer ramp-up.
- Confirm any "dormant" verdict using two windows: last {days} days AND last {days}*2 days. A partner who shows dormant on the short window but had activity in the longer window is intermittent, not dormant: drop to tier_watch instead of tier_offboard.
- Do not double-count partners who appear in both step 1 and step 2 with
zero activity (they're the same row).
- If a partner has no clicks but has conversions (server-postback only),
they are NOT dormant. Skip them.
- Cap email digest at top 50 per tier. Larger lists overwhelm the AM.# role
You are an Everflow ops assistant.
# inputs
api_key = {API_KEY}
network_id = {NETWORK_ID}
days = {DAYS} # default 30
new_partner_days = {NEW_PARTNER_DAYS} # default 30
seasonal_lookback = 365 # for spotting Q4-only partners
min_lifetime_value = 500 # USD, partners under this = "low value"
# task
1. POST /v1/networks/affiliatestable
- body: { filters: { account_status: ["active"] } }
- returns the full active partner roster with affiliate_id + name +
network_affiliate_id + time_created
2. POST /v1/networks/reporting/entity
- body: { from: today - {days}, to: today,
columns: [{column: "affiliate"}],
query: {} }
- returns clicks + conversions per active partner over the window
3. Cross-reference: any partner from step 1 NOT in step 2's results,
OR present with clicks=0 AND conversions=0, is a dormancy candidate.
4. Apply false-positive filters. Exclude a partner if ANY are true:
- time_created < today - {new_partner_days}d (too new)
- account_status != "active" (paused or archived intentionally)
- they had clicks or conversions in the prior {days}d window before this one
(intermittent activity, not dormant)
5. Score remaining partners by reactivation priority. For each, also pull
their lifetime stats:
- POST /v1/networks/reporting/entity with from = time_created,
to = today, columns: [{column: "affiliate"}]
Tier them:
- tier_high = lifetime conversions >= 50 OR lifetime payout >= 5000
- tier_watch = lifetime conversions 5-49 OR lifetime payout 500-4999
- tier_offboard = lifetime conversions < 5 AND lifetime payout < 500
6. For seasonal detection, check the same partner's activity in the
same window one year ago (today - 365d to today - 365d + {days}d).
If they had >0 clicks then but 0 now, tag them "seasonal_check" and
move to tier_watch regardless of lifetime score.
7. Format an email digest grouped by tier. For each partner show:
- name, network_affiliate_id, days_since_last_click, lifetime_payout,
lifetime_conversions, account_manager (if available), seasonal_check tag
- link to the partner's page in Core Platform
8. Return Markdown summary so I can verify counts before sending.
# guardrails
- Do not include partners with account_status = "paused" or "rejected".
- Min-tenure: exclude partners with `time_created` < today - {new_partner_days} days (default 30). New partners haven't been on long enough to confirm dormancy, they're still in onboarding. Default 30d; tighten to 14d for mobile, loosen to 60d for e-com with longer ramp-up.
- Confirm any "dormant" verdict using two windows: last {days} days AND last {days}*2 days. A partner who shows dormant on the short window but had activity in the longer window is intermittent, not dormant: drop to tier_watch instead of tier_offboard.
- Do not double-count partners who appear in both step 1 and step 2 with
zero activity (they're the same row).
- If a partner has no clicks but has conversions (server-postback only),
they are NOT dormant. Skip them.
- Cap email digest at top 50 per tier. Larger lists overwhelm the AM.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 reads your active partner roster and per-window clicks and conversions, then diffs them to surface partners that have gone silent; it has no partner tenure or last-click field, so recency is shown as silent-since buckets and you supply any new-partner exclusions.
=== AI PLAYBOOK RECIPE (MCP MODE) ===
Audit partners: Find dormant affiliates before they ghost you
Slug: partners-no-traffic-30-days
ROLE
You are an Everflow ops assistant with the Everflow MCP server connected (read-only). Use ONLY Everflow MCP tools (get_account_info, list_affiliates, get_affiliate, run_performance_report). Never call a REST endpoint, never write/modify anything.
GOAL
Surface dormant partners — ACTIVE affiliates that sent ZERO clicks AND ZERO conversions in the last 30 days, confirmed silent across a second window — then tier them by lifetime value, flag seasonal returners, and hand back an email digest grouped by tier so an AM knows who to re-engage vs sunset.
READ THIS BEFORE YOU START (how the MCP actually behaves — do not fight it)
• The performance report ONLY returns rows for partners that HAD activity. There is no zero-activity filter. Dormancy is a SET DIFF: full active roster MINUS partners that appear in the report. You must enumerate the roster and diff client-side.
• dimensions and metrics MUST be comma-separated STRINGS, never JSON arrays. dimensions="affiliate,affiliate_status" is correct; ["affiliate","affiliate_status"] returns INVALID_ARGUMENT.
• run_performance_report caps at 100 rows/page and 500 rows total. Set page_size=100 and paginate with cursor=next_cursor while has_more=true. If a response has result_capped=true, say so in the output.
• list_affiliates caps at 200 rows/page. Set page_size=200 and paginate with cursor=next_cursor while has_more=true.
• Dates are YYYY-MM-DD. Stay under 10 requests/sec (matters only in Step 9).
• There is NO partner creation-date / tenure field anywhere in the MCP and NO exact last-click date. Each is handled explicitly below — do not invent the data.
STEP 0 — Inputs
• WINDOW = last 30 days (default). Let TODAY be the account timezone's today. Define: CUR = [TODAY−30d … TODAY]; PRIOR = [TODAY−60d … TODAY−30d]; SEASONAL = [TODAY−1y−30d … TODAY−1y].
• NEW_PARTNER_IDS (optional, USER-SUPPLIED): a comma list of affiliate_ids onboarded in the last ~30 days to exclude from the dormant list. The MCP exposes no partner creation date, so this tenure filter is only possible if YOU paste the IDs (e.g. from your CRM/onboarding tracker). Leave blank to skip — the digest will note the filter was skipped.
STEP 1 — Context
Call get_account_info. Record network name, currency, and timezone. Do all date math in that timezone.
STEP 2 — Enumerate the active roster (the denominator, NOT the report)
Call list_affiliates with status="active", page_size=200. Paginate: repeat with cursor=next_cursor until has_more=false. Collect every {affiliate_id, name, labels, manager_id} into ROSTER. Record total_matching as partners screened.
STEP 3 — Pull current-window activity
Call run_performance_report:
from=<CUR start>, to=<CUR end>,
dimensions="affiliate,affiliate_status",
metrics="clicks,conversions,payout",
page_size=100.
Paginate with cursor=next_cursor until has_more=false. Build ACTIVE_NOW = every affiliate_id with clicks>0 OR conversions>0. (Postback-only partners — conversions>0 but clicks=0 — appear here, so they are AUTOMATICALLY excluded from dormancy; no separate filter needed. If any land in your dormant set, you diffed wrong.)
STEP 4 — Diff → dormant candidates
DORMANT = ROSTER minus ACTIVE_NOW (match on affiliate_id). Then remove any affiliate_id present in NEW_PARTNER_IDS. What remains: active partners with zero clicks and zero conversions this window.
STEP 5 — Second-window confirmation (guardrail — never flag on one window)
Re-run run_performance_report for PRIOR (from=<PRIOR start>, to=<PRIOR end>), same dimensions/metrics, paginated the same way. For each DORMANT partner:
• active (clicks>0 OR conversions>0) in PRIOR → tag intermittent (silent ≥30d but was active ≥60d ago) → route to WATCH.
• silent in BOTH windows → tag silent ≥60d (truly dormant).
STEP 6 — Lifetime value for tiering
Call run_performance_report for a wide window:
from="2015-01-01", to=<CUR end>,
dimensions="affiliate",
metrics="conversions,payout",
sort_by="payout", sort_direction="desc",
page_size=100.
Paginate up to the 500-row cap. Join lifetime {conversions, payout} onto DORMANT by affiliate_id.
• Dormant partner appears in this top-500-by-payout list → use its real lifetime conversions/payout.
• Dormant partner NOT in the list → below the top 500 lifetime earners, so treat lifetime conversions=0 / payout=0 for tiering.
• DATA CAVEAT: if lifetime payout comes back $0 for everyone (some networks don't populate payout), tier on conversions ALONE and state that in the digest.
STEP 7 — Tier each dormant partner
HIGH: lifetime conversions ≥50 OR lifetime payout ≥5000
WATCH: lifetime conversions 5–49 OR lifetime payout 500–4999
OFFBOARD: lifetime conversions <5 AND lifetime payout <500
Any partner tagged intermittent (Step 5) or seasonal (Step 8) is forced into WATCH regardless of the arithmetic — do not offboard someone who reliably comes back.
STEP 8 — Seasonal check
Re-run run_performance_report for SEASONAL (same calendar window one year ago), same dimensions/metrics, paginated. Any DORMANT partner active then but silent now → tag seasonal → route to WATCH.
STEP 9 — Enrich the SHORTLIST only (not the whole roster)
Within each tier, sort by lifetime value and keep the top 50 (the per-tier cap). ONLY for those shortlisted partners, call get_affiliate with affiliate_id and include="activity" to fetch:
• manager_name → the account manager for the digest, and
• the activity block (login_frequency_30d, portal_interactions_7d, performance_7d) → an abandoned-vs-quiet signal.
Do NOT call get_affiliate for every dormant partner — shortlist only, to respect the 10 req/s limit. There is no last-click date, so express recency as the silent-since bucket from Steps 3/5 (≥30d or ≥60d), not an exact number of days.
STEP 10 — Output: email digest (markdown), grouped HIGH → WATCH → OFFBOARD
Header:
Subject: Dormant partner audit — <network> — <CUR start> to <CUR end>
Line: <N> active partners screened · <D> dormant (<S> silent ≥60d, <I> intermittent, <Se> seasonal). Currency <cur>.
Per partner (under its tier heading):
• Name (ID) · labels · Account Manager: <manager_name>
• Silent since: ≥30d / ≥60d · tags: [intermittent] [seasonal] as applicable
• Lifetime: <conversions> conversions, <payout> payout (or: conversions only — payout not populated)
Close each tier with one recommended action:
• HIGH → personal re-engagement from the AM.
• WATCH → automated nudge / check for seasonality before acting.
• OFFBOARD → candidate for bulk sunset.
Caveats footer (include only the ones that applied): Tenure filter skipped — MCP exposes no partner creation date (supply NEW_PARTNER_IDS to enable). · Recency shown as silent-since buckets — MCP exposes no last-click date. · Payout not populated — tiered on conversions only. · A report page hit result_capped=true — lifetime tiering covers the top 500 earners.
GUARDRAILS
• Read-only: only get_account_info, list_affiliates, get_affiliate, run_performance_report. Never create or modify.
• Two-window rule: never call a partner truly dormant on a single window (Step 5 is mandatory).
• Cap 50 partners per tier in the digest.
• Expect the count to scale with the network and with how many referral/self-signup partners never send traffic: a roster with many never-active signups can return a large dormant set — that is correct, not a bug. On a typical client network expect a handful to a few dozen.
=== END RECIPE ===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 and Affiliates is enough, and use your Network Operating Partner key, not the Reporting key.
Decide your dormancy window
Default is 30 days. Lead-gen and iGaming usually run 30. E-com brands with longer purchase cycles can run 60. Mobile usually runs 14.
Decide your "new partner" guardrail
Partners onboarded in the last 30 days get excluded automatically so you don't chase someone who hasn't even launched yet.
Run the prompt
With MCP connected, just run the prompt as written. On the API tab, first replace {API_KEY}, {NETWORK_ID}, {DAYS}, and {NEW_PARTNER_DAYS}, then run it.
Read it in Claude, ChatGPT, or Gemini
First run gives you the dormant list grouped by tier: high-priority reactivation, watch list, and safe to offboard. The summary lands in 30 to 60 seconds. The same prompt works in any of the three.
Yes. Reporting can group by affiliate and filter for zero clicks in a window. What it doesn't do is the scrub layer: separate dormant-on-purpose from genuinely-needs-outreach from should-be-offboarded, exclude brand-new partners (<30 days) who don't have a baseline yet, filter low-volume-but-high-quality partners who legitimately ran zero this month, and group the remainder by recommended action. The recipe handles all of that and drops the list as a single email instead of a manual filter-and-scroll workflow.
Skipped by the new-partner guardrail. Anyone added in the last 30 days (configurable) is excluded so you don't chase someone who's still in onboarding.
Handled by the seasonal guardrail. The prompt checks the same date window one year ago. If a partner had activity then but is dormant now, they get tagged seasonal_check and moved to the watch list regardless of lifetime score, so you don't accidentally offboard your Black Friday star in March.
False positives the recipe handles. Paused on purpose (network operator put them on hold, surfaced as "paused, no action"). Brand-new (<30 days history, no baseline, listed separately under "new this period"). Seasonal (zero activity is expected for this time of year, flagged by year-over-year comparison if 12+ months of history). Low-volume-but-high-quality (partners with high CVR and small but consistent revenue; the recipe excludes from "offboard" recommendations if last 90 days revenue > $500).
What the recipe doesn't do. It doesn't make the offboard decision for you. It groups partners into "reactivate / pause / offboard" buckets with reasoning, then waits for human review. The whole point is making the manual scrub take 10 minutes instead of 90, not bypassing the judgment call.
Bulk action support. Some networks (large-network-scale) want to bulk-inactivate hundreds of dormant partners at once. The recipe outputs the list in API-callable format so the bulk action can be a follow-on script. Don't run that auto-fire, keep the human review step.
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.