Many of the visitors who click your paid search ads don’t complete a purchase on the day of their click and initial visit, but instead come back some number of days later and buy.

The paid search engine tracking tools and major web analytics packages can (generally) track these delayed purchases. They assign credit for this delayed revenue back to the paid search channel and even the engine, campaign, ad-group, and keyword responsible for the click.

Most use a 30-day timeframe during which delayed purchases are credited properly. Some allow you to specify the timeframe – SiteCatalyst/SearchCenter for example allows you to track delayed purchases for up to one year. (Set the evar expire date in the Admin control panel.)

But there is a timing problem in PPC reports. They show the clicks/expenses for the requested period, and the orders/revenue that took place in the requested period. But there is no requirement that the reported clicks cause the reported revenue. In fact, it’s an open secret that in many cases they don’t.

(There are other issues causing inaccuracies in these reports too, as posted earlier.)

There are three sources for the data in a paid search report:

• Left-Over Transactions. Revenue from clicks/visits that occurred prior to the initial reporting date. The clicks and expense of these clicks is not included on the report.

---

• In-Period Transactions. Clicks and their resulting revenue when both occurred inside the reporting dates.

---

• Incomplete Transactions. Clicks and their expense for which some of the orders and revenue occur after the final reporting date. These orders and revenue are not included in the report.

So for a report on paid search ‘last month’ in a company which has trailing sales for about three weeks after the initial click (not at all atypical), the report would include:

• A stream of left-over transaction revenue, starting with 21-days worth the first day of the month stretching all the way into the third week of the month.

---

• A good number of in-period transactions where the click occurred on or after the 1^st of the month and the sale closed by the last day of the month

---

• The full expenses but an unknown amount of revenue for incomplete transactions from every day except the first week of the month. It should be noted that the revenue from these incomplete transactions never ‘fills-in’ for the ‘last month report’. Even if you wait the full 21 days and then run it, it will report the same revenue total it did on the 1^st of the new month.

The theory or justification for allowing this sloppy mix of data to pass for an actionable report is this: the left over transaction revenue is probably equal to the incomplete transaction revenue. So on-balance the report is probably pretty accurate.

And in some cases that’s probably true.

Unless your business has seasonality. Or product line changes. Or sales/promotions by either you or your competitors. Or impact from weather or other external major events. Or unless you add, delete, or modify your keywords. Or change your bids. Or test new ad-creative. Or work on your landing pages. Or in any other way change anything that might impact your customers, market, business, campaigns, or website.

Depending upon the degree to which you do any/all of those things, you’re going to need to take these reports with a proportionately large grain of salt.

• If you’re working aggressively on your PPC campaigns, trimming keywords (because the reports you now know you maybe shouldn’t trust told you that they weren’t making you any money – ah the irony), narrowing match types, and lowering bids, for example, you’ll see an exaggerated improvement in the following period as left-over revenue continues to come in from your old running keywords, higher-priced bids, and broader matches.

---

• Seasonality such as that we experience with a number of major apparel manufacturers, causes an artificial boost in some campaigns as a new season kicks in, as sales pickup aggressively from all the pre-season shopping that went on in the preceeding weeks. Another side effect from the current reporting method is that we don’t gain accurate visibility into when starting pre-season advertising is a good idea. With true-attribution we’d know.

---

• As promotions or seasons end, you get the opposite effect with exaggerated swings down. Now fewer latent conversion occur due to pricing or inventory issues, making a lot more of last periods click-cost become a lot less profitable (and perhaps even pushing into the red) more than any report will show.

Why Not Do It Right?

First let’s define who we’re talking about. As far as I know, everybody creates their paid search reports using the erroneous methods described above. Google, Yahoo, MSN, Google Analytics, IndexTools, and Omniture SiteCatalyst/SearchCenter are the ones I’m familiar with. Please leave comments if you know of any package that can properly relate clicks to revenue.

The obvious question is why. Why don’t paid search reports match clicks to their resulting revenue? Why doesn’t last month’s report include only the clicks that took place during that month and the sales that resulted from those clicks?

The answer seems to just be that this is how it’s always been done. It’s undoubtedly easier computationally. There are interface issues to doing it the way I’m suggesting.

Since the same software doing this reporting (the engines or your analytics package) knows both the average number of days for your latent conversions and the number of days for which they’re configured to allocate sales (as well as their allocation rules relative to multiple visits, but we’re leaving that complexity out of this discussion) a ‘last month’ report could include a simple flag disclaiming that ‘Report Incomplete – Additional Revenue Expected for 17 more Days’ or whatever.

Using accounting terms, it’s time paid search reporting moved from a cash to an accrual basis.

I don’t know why. I’ll see if I can’t get some folks from the engines or analytics vendors who might be willing to talk about this ‘on the record’ for a future post.