publisher-performance-review

name

publisher-performance-review

description

Use this skill when an agency operator wants a deep dive on one publisher for a brand, usually as prep for a partner call: that publisher's clicks, conversions, EPC, average order value, commission, status split, and trend over time, with talking points for the conversation. Trigger on: "Review CashbackCo for Acme", "Prep me for the call with [publisher]", "How is [publisher] performing on [brand]?", "Pull a publisher review for [partner]".

Operating instructions

You are producing a single-publisher performance review for one brand: a focused profile of how one partner is performing, built so the account manager can walk into a call knowing the numbers and the story behind them. Unlike programme-performance-report (every publisher), this skill is about one partner across the period.

Step 1 — resolve the brand

If the user did not name a brand, ask which one. Do not guess.

Call affiliate_resolve_brand. If the user named a network, pass { network: "<slug>" } to filter; otherwise call with no arguments and filter the result to the brand the user named.

The response is an array of { brand, network, networkBrandId }. Reduce it to the bindings whose brand matches the user's brand. If none remain, tell the user the brand is not registered, suggest affiliate_resolve_brand with no args to see what is, and stop.

Call affiliate_list_networks once and retain the metadata for those bindings. Use each network's knownLimitations when deciding whether clicks or another field are genuinely observed. Do not interpret a normalised zero as observed zero when the network says that metric is unavailable.

Step 2 — identify the publisher

Publisher ids are network-specific. Call affiliate_<network>_list_media_partners for each binding and match the user's named partner against name separately on each network:

• Awin advertiser: affiliate_awin-advertiser_list_media_partners({ brand })

This returns MediaPartner[] with id, name, status. Record a separate publisherId and relationship status for every matching network binding. If a name matches more than one partner on a network, list the candidates and ask which. If it matches none on one network, report that gap and continue with the remaining bindings. Stop only when no binding has a match.

Step 3 — pick the windows

Default period: the last 90 days, ending today, so the trend is visible. Honour explicit windows. Compute a comparison window of the same length immediately prior for the period-over-period view. Express all dates as ISO YYYY-MM-DD. State both windows at the top.

Step 4 — fetch this publisher's performance per binding

For each matching (brand, network, publisherId) tuple, call the performance tool once for the current window and once for the comparison window. Pass that network's publisher id so the network returns only that partner's rows:

• Awin advertiser: affiliate_awin-advertiser_get_programme_performance({ brand, from, to, publisherId })

Pass brand exactly as it came back from affiliate_resolve_brand. Each call returns ProgrammePerformanceRow[] with: date, publisherId, publisherName, clicks, conversions, grossSale, commission, currency, status.

Defensively keep only rows whose publisherId matches the id passed for that binding. If a call returns other publishers, exclude those rows and flag that the network did not honour the filter.

If a call fails, surface the verbatim error (network, operation, message, httpStatus). Do not silently treat a failure as zero. Continue with the remaining bindings and flag the gap at the top.

Step 5 — write the review

Output in this order:

1. Partner and period: publisher name, relationship status, the brand and network, current window and comparison window (each with day count).
2. Headline: clicks, conversions, gross sale, commission for the current window, each with the comparison figure and delta (absolute and percent). Per-currency lines where the partner spans currencies; never invent an FX rate. Label clicks as unavailable where the network's limitations say they are unavailable; do not present a normalised zero as observed zero.
3. Derived metrics: conversion rate (conversions / clicks), EPC (grossSale / clicks), average order value (grossSale / conversions), and effective commission rate (commission / grossSale). Compute only where the denominator is non-zero and the underlying metric is known to be available; otherwise say "not computable" and why.
4. Status split: the partner's grossSale and commission by status (pending / approved / reversed). Flag a reversal share materially worse than the comparison window.
5. Trend: a short month-by-month (or week-by-week for short windows) line so the direction is visible.
6. Talking points: three to five plain-language observations for the call — what's working, what's slipped, and questions the data supports (for example, "reversals doubled; ask whether their traffic mix changed"). Only points the figures support. When advisory client strategy is available, use it as context; never present a suggestion as an approved commitment or action.
7. Failures (if any): per-network verbatim error from the envelope.

Matter-of-fact tone, UK spelling, no hype.

Constraints

• Never invent figures. If a row is missing, say "no data" — don't backfill zeros.
• Compute derived metrics only where the denominator is non-zero and the source metric is available. Treat unavailable normalised zeros as unknown.
• Currency: respect the per-row currency. If the partner spans multiple currencies, output each separately. Don't normalise across networks.
• Talking points must follow from the data. Do not invent partner intentions or commitments.
• Do not claim a partner's rank without comparing it against the other publishers in the programme.
• An inactive or pending partner may have little or no performance data — say so plainly rather than implying the partner has churned.