The Pull/Push Dichotomy - or why most reportals fail

One of the biggest differences between reporting methodologies is whether they are push or pull. A push technology is one where the vendor pushes information to the client, an approach which tends to result in more of the information being read. The classic push approach is email, where the vendor sends the results, or a link to the results, to the client, with an expectation that it will be acted on.

A pull technology is one where the client collects the information when they wish to. Examples of a pull technology include reportals, FTP sites, and the online reporting built into many Internet based data collection systems. Systems which deliver the power to search and trawl the data, such as Quanvert, are also examples of pull techniques.

At first glance, the pull approach seems more client friendly, and likely to be of more utility. The client knows what he or she needs, they can collect exactly the data or analysis they want, and they are not burdened with reports, tables, or data streams which are not relevant to their current needs.

However, most pull systems have been fairly unsuccessful. One problem is that many clients do not have the time to visit a number of different provider sites to access the various elements they might need. Clients are often unsure of exactly which bits of large data systems they need to access, they do not want to learn several different procedures (nor store a raft of passwords) in order to answer an urgent question. Off the record, many vendors have commented that when they have provided their information in a pull environment, some client never access it, rendering it very poor value, and making the project less likely to be funded in the future.

Push systems, such as emailing results to clients, are based on vendors wanting clients to access information. The vendor tends to know what is interesting in the information, and has a financial interest in ensuring that the client is aware of, and reads, interesting things in the data/information.

Pull systems seem to be most effective when they are delivering access to data rather than insight, and where the information is necessary to the client (as opposed to desirable), and where the amount of information is so large that the client might be over-burdened if the information was sent straight to them. Examples that work well with pull systems are audit data (such as that provided by AC Nielsen), news services (although even here people are starting to use things such as RSS to simulate a push service), and process information (such as accounts, sales, and transactional data such as number of visitors, number of page views etc.).

Push systems appear to have a distinct advantage over pull systems when the material being delivered is more insight focused, rather than data driven, and in cases where the information is ‘nice to have’ rather than essential – something which is often the case with market research data.

Some services provide a hybrid of pull and push. The underlying data might be made available via a reportal (i.e. a pull modality) but key findings are automatically emailed to the client, perhaps as dashboard results.

Comments

[Mario]

I was probably way too early, but I did experiment delivering traditional crosstab analysis via RSS a couple of years ago. In other words, you could subscribe to a project "feed" in your aggregator, and whenever the crosstab analysis was updated (e.g. re-run with new/more data, changes made to crosstab definitions etc.), these new tables would appear as new posts in the feed reader/ aggregator.

Maybe now is the time to revisit... at the time I think the concept of RSS and feed aggregrators was still unfamiliar amongst MR professionals (maybe it still is?)