Reporting

This article is the entry point for MPO reporting. It explains:

• What types of reporting MPO supports.
• When to use the Standard Reporting API vs. the Real-Time Asynchronous API.
• How to think about identifiers (seller, campaign, seller-campaign) and time grains.
• Typical integration patterns for marketplaces.

Detailed endpoint behavior and request/response examples live in the dedicated articles:

• MPO Standard Reporting API – aggregated, historical statistics.
• MPO Real-Time Asynchronous API – low-latency, asynchronous exports for operational monitoring.

1. Reporting building blocks

MPO exposes a consistent set of concepts across both Multi-Seller and Single-Seller setups.

1.1 Core identifiers

You will mainly work with:

• sellerId – marketplace seller (independent of campaign model).
• campaignId – MPO campaign (shared Multi-Seller campaign or Single-Seller template campaign).
• (sellerId, campaignId) pairs – the seller-campaign view.

These map to three standard stats endpoints:

• /stats/sellers – one row per seller per interval.
• /stats/campaigns – one row per campaign per interval.
• /stats/seller-campaigns – one row per (campaign, seller) per interval.

1.2 Core metrics

All MPO stats endpoints share the same metric vocabulary (see Standard Reporting API for full definitions):

• Volume: impressions, clicks
• Spend & revenue: cost, saleUnits, revenue
• Efficiency: cr, cpo, cos, roas

Metrics are defined identically for Multi-Seller and Single-Seller; only the aggregation key (seller, campaign, seller-campaign) changes.

1.3 Aggregation interval

Both reporting APIs let you choose the time grain, for example:

• Hour – for short-window analysis.
• Day – standard granularity for dashboards and exports.
• Month / Year – long-term trend and finance views.

Exact options and range limits depend on the endpoint and environment (see individual API pages).

2. Choosing between Standard and Real-Time reporting

MPO offers two complementary reporting paths:

• Standard Reporting API – aggregated, post-processed statistics.
• Real-Time Asynchronous API – near real-time, asynchronous exports.

2.1 High-level comparison

2.2 When to use which

Use the Standard Reporting API when you need:

• Aggregated metrics over longer periods (for example, last 30 days, last quarter).
• Stable data for billing, margin analysis, and long-term trends.
• Scheduled batch exports into your own reporting stack.

Use the Real-Time Asynchronous API when you need:

• Short-window metrics for live monitoring (for example, last 60–120 minutes).
• Visibility right after budget changes, campaign launches, or template updates.
• Near real-time dashboards and alerts for operations teams.

In most integrations you will use both:
Real-Time for “is everything behaving right now?” and Standard for “what happened this week/month, and how does it impact revenue?”

3. How Multi-Seller and Single-Seller reporting fit together

The reporting surface is shared across Multi-Seller and Single-Seller:

• Same endpoints – /stats/sellers, /stats/campaigns, /stats/seller-campaigns.
• Same metrics – impressions, clicks, cost, saleUnits, revenue, cr, cpo, cos, roas.
• Different interpretation of IDs:
  • Multi-Seller:
    • campaignId → shared MPO campaign across many sellers.
    • sellerId → marketplace seller within that pooled campaign.
  • Single-Seller:
    • campaignId → usually the template campaign ID.
    • sellerId → remains the primary key for seller-level performance.
    • In some APIs you also see a dedicated sellerCampaignId that identifies the per-seller instance.

From a reporting perspective:

• Use Seller Stats when your question is “How is this seller performing overall?”
• Use Campaign Stats when your question is “How is this MPO campaign or template performing?”
• Use Seller-Campaign Stats when your question is “How is this seller performing inside this campaign?”

4. Click attribution policy

For derived metrics (saleUnits, revenue, cr, cpo, cos, roas), you can control how sales are attributed to clicks using clickAttributionPolicy:

• SameSeller – only count sales where the purchased product’s seller matches the seller that was clicked.
• AnySeller – count sales that follow a click on any seller’s product (cross-seller attribution).
• Both – return both perspectives where supported.

This policy is available across the Standard Reporting API endpoints. Use it to align MPO reporting with your internal business rules for marketplace attribution.

5. Typical integration patterns

5.1 Daily batch export for BI and finance

• Once per day (or more), call Seller Stats and Campaign Stats from the Standard Reporting API for the previous day.
• Load results into your data warehouse and join with internal catalog and seller metadata.
• Use this layer for:
  • Finance and invoicing.
  • Marketplace P&L and margin analysis.
  • Executive dashboards and long-term trend analysis.

5.2 Seller-facing reporting

• Use Seller Stats and, when needed, Seller-Campaign Stats (Standard Reporting).
• Filter by sellerId and aggregate over windows such as last 7 days or last 30 days.
• Surface these metrics in your seller portal, aligned with internal KPIs (GMV, ROAS, spend caps, etc.).

5.3 Operational monitoring and diagnostics

Combine both reporting paths:

• Use the Real-Time Asynchronous API to:
  • Confirm today’s changes (new budgets, productSet updates, activations) start generating clicks and spend within minutes.
  • Power live NOC-style dashboards and alerts.
• Use Seller-Campaign Stats (Standard Reporting) to:
  • Drill into under-performing sellers within a campaign.
  • Compare sellers before and after configuration changes.
  • Understand whether issues are campaign-wide or isolated to specific sellers.