And all of that is when everything goes right. Too often, something snags in the process. Complications are to be expected in a complicated process. However, sometimes it is the vendors that provide the complications, through issues with their reporting tools.
There are a couple of basic things that I am often surprised that vendors like DoubleClick, Atlas, Pointroll and others forget. Examining them individually will give a better idea of the complications they present.
The first issue is changing report formats or reporting tools without notice. Many publishers have extensive automation of report processing or extensive training of their reporting staff. Neither reacts well to sudden changes in format of a report. Imagine spending a couple of days writing the transformation routines to normalize a vendor's data and 2 weeks after you put the routines into use, the vendor changes the standard report format without notice. The tool breaks outright, or worse puts out questionable data.
Vendors should understand that there are dependencies on their reports. Having an idea of how to add new value to a reporting function or output is great, but the implementation must be done with consideration of all the users. Just because one consumer of the reports thinks it would be great to add a column with a given metric or placement code added, doesn't mean all consumers of the report will agree.
The second issue that we often see challenges with is the output format of the reporting itself. I'm not talking about the file format per se, but the internal formatting. Some vendors have obviously put a lot of work into a canned report format with too much, well... format. Colors, merged cells, extensive calculations or grouping are not helpful for automation. We spend a lot of time removing the formatting and features that they no doubt worked very hard to add.
When designing their reporting tools, media vendors should start with basic reporting formats that have little added. The design should focus on a simple header and rows of data. Once that has been accomplished, then they can make versions available that add value and have bells and whistles.
The third complication has to do with the aggregations available from the vendor's reporting tool. Specifically the date ranges. Some vendors don't allow reporting based on specific date ranges, while others arbitrarily limit the number of days that can be included. The first limitation really hampers pacing and billing for short flights or day targeted flights. The limitation on the number of days included impacts longer contracts and flighting periods, requiring multiple pulls of the data and manual work to piece them together.
Vendors should all understand that the ability to pull daily data by a specific range of any length is a minimum requirement for their reporting tool. Monthly only aggregation is not sufficient and requiring 8 data pulls to get the data for a single year long contract doesn't make sense. Do a little architecture work and open up those limitations folks.
The fourth issue has to do with time zones. Most vendors have figured this out, but some still have tools that are not clear about what time zone the report is based on. The IAB recommends that European delivery be reported on GMT (Greenwich) and North American delivery be reported on Eastern Standard (New York) time.
The big vendors, DoubleClick, Atlas and Pointroll all have some method of addressing this, but some smaller vendors haven't gotten it quite right yet.
When building a reporting tool and thinking about the issues of time zones, vendors should consider the following minimum standards. The time zone the report is based on should be fully adjustable for all time zones globally with a simple adjustment to based on GMT. The time zone should be clearly noted on the reporting tool and in the report itself (in the header).
As a bonus and a feature I would love to see, when a user selects a day and time period the system should check itself and determine if data has been validated through the end point of the request. If not, the system should warn the user at that point that data is not verified through the end of their request. Not a single vendor has this function and every one of them should.
The fifth and final issue I will cover here is the ability of the vendor's tool to automatically forward data. Push reporting, scheduled reports, automated reporting, call it whatever you want. This function is mostly limited to the larger vendors at this point, but the mid level and even niche vendors should get this added to their tools as soon as possible.
There are a few functions that can be included in push reporting that really make automation easier for the publisher. During setup, the user should be allowed to add content to the subject line of the email and the name of the file attachment containing the report. The available file formats should include at least comma separated values (csv) and Excel. When building the functionality, I think the path of least resistance is for the vendor to simply allow the user to save and schedule a report they have already created. Attempts to make a scheduled report tool from the ground up always seem to result in a limited tool, but efforts that leverage the existing tool give all its function.
Those are the top 5 challenges presented by vendor tools as a whole. Some are better at addressing one challenge or another. Small to medium sized vendors should remember that all 3 major online advertising media vendors do at least an adequate (but not perfect) job of all 5 of these. If you want to join one of the big ones, your reporting tool needs to be better.
Daniel Dowling is a Senior Analyst with a top 10 online publisher. With a primary focus on reporting and analyzing third party serving and tracking data.
Mr. Dowling has a deep understanding of the reporting issues publishers face. Additional material can be located at Mr. Dowling's website located at http://thirdpartyadvertising.lostmyring.com.
