The conversion count showing in the dashboard of an affiliate service provider (ASP) and the affiliate orders you calculate from your own revenue data don't agree. You keep matching them up on the assumption that a setting is wrong somewhere, and the two still never line up. Both are correct. What each side is counting is a different thing.
Contents
TL;DR#
- A conversion displayed in an ASP dashboard is still unapproved at the moment it fires. It doesn't become a payout until the advertiser has checked it against the conversion conditions and the rejection conditions
- The conditions for crediting a conversion differ from network to network. ValueCommerce counts 60 days from the click, Rakuten Affiliate requires the item in the cart within 24 hours and the purchase completed within 89 days, and Amazon Associates counts within a single session
- What your own side sees changes with the link format. Programs where you can attach utm_medium=affiliate show an affiliate channel in both GA4 and RevenueScope; programs where you can't are mixed into Referral or Direct
- Neither side wins the argument. Fix on the real revenue counted by last-touch on your own side, and the ASP's numbers can be read as a pre-rejection estimate
1. An ASP Conversion Isn't Revenue Until the Advertiser Approves It#
The conversion count showing in an ASP dashboard is a figure that includes unapproved estimates. The payout isn't settled at the instant the conversion conditions are met; until the advertiser has checked the contents and approved it, it is neither a cost nor revenue.
Counts failing to agree because of a difference in how they are calculated is not specific to affiliate marketing; it happens across advertising generally. Ad and GA4 CV counts don't match works through that general mechanism. Here we narrow to the three things that happen only in affiliate marketing: an approval step with a human judgement in it, a target period that differs from network to network, and a structure where what your own side sees changes with the program.
A conversion that has fired is not yet approved#
A8.net's help states plainly that meeting the conversion conditions does not automatically make a conversion approved[1]. The state right after a visitor who clicked an ad finishes an application is "unapproved conversion," and from there the advertiser checks the application contents one at a time. Does it meet the conversion conditions? Does it fall under the rejection conditions? Only what passes that check and is judged approved becomes a payout, and what is judged cancelled disappears.
What gets rejected is an order that did go through#
The approval work is not the work of doubting whether an order is genuine. Returns, cancellations, duplicate orders from the same person, incomplete entry details. Conditions for not crediting a conversion even though the order itself went through are set program by program. In A8.net's advertiser-facing dashboard as well, approval is built to be carried out order by order[2].
This is the point where it differs decisively from ad measurement. An ad CV is counted mechanically once the conditions are met. An affiliate conversion then passes through a step where a person looks at it and drops some of it. The difference isn't a mechanical difference in how the calculation runs; it's that a human yes-or-no sits in the middle. The same help recommends running this approval processing on a regular schedule, such as once a day[2]. Until that processing runs, the counts pile up in the dashboard still unapproved.
So the dashboard count moves after the closing date#
Approvals and rejections don't necessarily finish inside the month the conversion occurred. Rejection can be settled after the period for accepting returns has closed. A count you were looking at as last month's shrinks once this month arrives. Your own revenue data doesn't move once the order is confirmed, so the size of the difference changes every time you compare the same month again later. You are pushing data that moves later against data that doesn't.

2. The Lookback Differs by ASP and by Program#
Sixty days from the click. In the cart within 24 hours and the purchase completed within 89 days. Within the single session that starts with a click on a special link. These are the conditions for crediting a conversion that ValueCommerce, Rakuten Affiliate and Amazon Associates each publish. Compare only those three and neither the starting point nor the length lines up.
The published conditions differ even in where they start#
ValueCommerce sets the expiry of the cookie used to track visitors at 60 days. The wording is that orders occurring within 60 days of the click are reflected in the order management screen[3]. Rakuten Affiliate watches two deadlines at once. The case that qualifies is an item put into the shopping cart within 24 hours of the click and a purchase or application completed within 89 days of the click, with some services carrying a 30-day expiry[4]. Amazon Associates divides by session rather than by days. A session begins with a click-through on a special link and ends at whichever comes first: 24 hours after the click, the moment a product is ordered, or the moment the visitor arrives at the site through a different special link[5].
Beyond the length in days, what the three treat as the starting point differs. One looks only at the time of the click, one looks at both the cart and the completed purchase, and one looks at the break between visits.
There is no shared rule that cookies last 30 days#
The figure of 30 days you often see in affiliate explainers is not a general rule of the industry. What is actually published is the three above, and 30 days is an exceptional value that appears for some Rakuten Affiliate services. Decide your own aggregation period is 30 days on the assumption that 30 is the default, and it still won't agree with the numbers from a network that credits conversions at 60 days. The mechanism by which changing the lookback changes which touchpoint gets credited for the same purchase is worked through in what a lookback window is.
Conditions are set per program as well#
Conditions are set per advertiser even within the same ASP. So the work of settling on "this ASP is N days" and pushing that against your own data doesn't hold up in the first place. If you have ten programs in partnership, one dashboard holds data counted over ten different target periods. Your own analytics tool can only pick one period, so wherever you set it, the remaining programs sit out of line.

3. One Order Counts Twice on One Side and Scatters on the Other#
A8.net's advertiser-facing dashboard has a function on the approval screen for checking order numbers for duplicates[2]. That the same order can be counted as two conversions is anticipated as a function.
On the ASP side, one order becomes two#
Look at a comparison site, read a review blog, then buy through a points site last. This way of moving is not unusual. If the media passed through are each registered with a different ASP, one and the same order is credited as a conversion at several ASPs. Duplication across ASPs is something no ASP can see. That is why it is built so the advertiser has to notice it at the approval step and drop it. Against one order, the dashboard displays figures amounting to two conversions.
What your own side sees changes with the program's link format#
Your own revenue data, on the other hand, looks different depending on the program. For programs where you can attach a marker of utm_medium=affiliate to the link, an affiliate channel appears in both GA4 and RevenueScope. In GA4's default channel group as well, the condition for judging affiliate is that the medium is affiliate[6]. Programs where you can't attach a marker either land in Referral under the linking domain, or lose the referrer information while passing through several ASP redirects and mix into Direct. The same single order is one row in the ASP dashboard and is distributed to scattered places on your own side depending on the medium.
The directions of the discrepancy are opposite too. On the ASP side one order grows into two rows; on your own side that same order is attributed by last-touch to exactly one touchpoint. Because the side that reads high and the side that reads low happen at once, you can't narrow the cause of the difference to one thing.
The way of reading referrer traffic by revenue efficiency rather than session count is covered in what referral traffic is, and the reason revenue that ties to nothing structurally remains is covered in unattributed revenue.
Reconciliation starts over every time a month turns#
Approvals and rejections occur across month boundaries. The table you reconciled as last month's changes again with this month's rejection processing. So reconciliation doesn't finish in one pass; it turns into counting the same month over and over. Because the target period differs per program, wherever you set your own side's period, the remaining programs stay out of line. And every time a publishing partner is added or stops, the cut has to be rebuilt as well.
The idea of checking reported figures against your own data is the same one in checking an agency's monthly report against your own data. Put a single fixed point on your own side and the ASP's numbers become readable as a pre-rejection estimate.

RevenueScope solution
RevenueScope gives this affiliate comparison a stable reference point. Approvals and rejections changing across month boundaries is the ASP's own circumstance, so what you place on your own side is a figure that doesn't change across month boundaries. Programs where you can attach a marker of utm_medium=affiliate to the link are counted as the Affiliate channel. Inside that channel, you can open it up by utm_campaign with sessions, revenue, RPS (revenue per visit), AOV and CVR. Assign a campaign name per program or per medium and you can follow how much each medium earned in figures measured on your own side.
Programs where you can't attach a marker land in Referral or Direct by referrer, and revenue across all channels including those can be compared by switching the attribution model (last_touch / first_touch / linear / time_decay). Revenue that ties to no touchpoint is displayed as Unattributed.
Asking an AI assistant through MCP returns this#
Ask "Open up the Affiliate channel by campaign with sessions, revenue and RPS" and it comes back in the following form.
| Campaign | Sessions | Revenue | RPS |
|---|---|---|---|
| point-media_2607 | 2,480 | ¥62,000 | ¥25 |
| coupon-media_2607 | 1,260 | ¥41,000 | ¥33 |
| comparison-site_2607 | 3,120 | ¥218,000 | ¥70 |
| review-blog_2607 | 540 | ¥149,000 | ¥276 |
This affiliate-channel comparison is illustrative. The figures are fiction, written to explain the point.
What is working here is the place where the order by traffic sent and the order by efficiency don't agree. The points-site type is second by traffic sent, but its RPS is the lowest of the four. The review type sends the least traffic and yet its RPS is close to 4x that of the comparison-site type. At the same time there are media like the comparison-site type that sit high on both traffic and efficiency. Look only at the ASP's conversion counts and this difference in ordering never appears. Which medium gets a special rate, and where product assets are directed, is settled by this efficiency rather than by the count.
FAQ#
Frequently asked questions#
Q. Which is right, the ASP dashboard or our own revenue data?
A. Both are right, and what they are calculating is different. The ASP calculates applications that met the conversion conditions; your own side calculates revenue from orders that were confirmed. It isn't work of correcting one to match the other — it's work of deciding which one is the fixed point for your judgement.
Q. If we install RevenueScope, will it match the ASP's conversion count?
A. RevenueScope doesn't integrate with ASPs, so it doesn't handle approval or rejection decisions. What it provides is revenue and RPS per campaign, measured on your own site. Put that value at the fixed point and the ASP's numbers can be read as a pre-rejection estimate.
Q. How close should the ASP's numbers and our own numbers get?
A. Matching isn't the goal. The lookback conditions differ per program, and approvals and rejections change later, so the harder you push them together the more monthly work you create and nothing else. What you decide is which of the numbers you place as the basis of judgement.
Q. Isn't the cookie expiry 30 days?
A. Thirty days is a figure you see often, but it is not a shared default. ValueCommerce is 60 days, Rakuten Affiliate is a cart within 24 hours plus a purchase completed within 89 days, and Amazon Associates is within a single session. Check the official help of the ASPs you have partnered with.
Summary#
The ASP dashboard and your own revenue data will not agree however you correct the settings. The ASP counts conversions including unapproved ones, approval is settled by a human judgement, the conditions for crediting a conversion differ per program, and what your own side sees changes with the link format. Stop the work of making them agree, settle on the real revenue counted by last-touch on your own side as the fixed point, and the ASP's numbers become readable as a pre-rejection estimate. Not which of the ASP dashboard and your own revenue you should correct to make them agree, but which one you hold as the fixed point and compare against every month — has your EC site already decided that?
See which ads actually drive revenue, at a glance
Free up to 5,000 sessions/month, AI connection included. No credit card required. Up and running in 5 minutes.
References#
- [1] A8.net Help "What is an 'unapproved conversion'?" (2026)
- [2] A8.net Help for Advertisers "[New dashboard] Conversion approval" (2026)
- [3] ValueCommerce "Cookie — ValueCommerce Glossary" (2026)
- [4] Rakuten Affiliate "How many days after a link is clicked does a commission apply?" (2020)
- [5] Amazon Associates "Associates Program Policies" (2026)
- [6] Google Analytics Help "[GA4] Default channel group" (2026)



