How Multitouch Analytics Works

Overview

Multitouch Analytics uses a cookie to store a visitor's history of touches on each channel. The cookie is managed through the multitouch.js Javascript library. Whenever a visitor lands on one of your pages, the multitouch() javascript function is invoked and that records the touch in the cookie. If the visitor is just navigating internally within your site, nothing is recorded - only cases when a visitor arrives directly or by referral from another site (or search engine, or email link, etc) are recorded. The library works out the channel for itself - organic search, direct visits and referrals from third party sites are determined from the referring URL, and other marketing campaigns are taken from the utm_source and utm_medium parameters in the URL (these are the same parameters as used in Google Analytics to track marketing campaigns such as Adwords, Email etc).

When the visitor makes a purchase, the multitouch_send_event() javascript function is invoked and that firstly records the order in the cookie, and then sends a summary of touches from the cookie to Google Analytics using the asynchronous mode.

Data is collected in Google analytics as events. The event data can be downloaded and analysed via the Google Analytics API. An analysis package, multitouch_report.pl written in Perl, is available to do this.

The reports include:

  • Channel Overlap - A summary of the amount of overlap between channels, in terms of:
    • The number of transactions touched by 1 channel, 2 channels, 3 channels etc
    • The number of transactions touched by different combinations of channels, e.g. if the channels are A, B and C, the report separately shows the number of transactions for each of channel A, B, A+B, A+C, B+C, A+B+C.
  • All Attribution Report - A summary of marketing channels and number of transactions to which each channel had some contribution.
  • Even Attribution Report - A summary of channels with even distribution of each transaction, i.e. if 3 channels were involved (regardless of the number of touches), each channel is allocated 1/3 of the transaction.
  • Distributed Attribution Report - Summary of channels and a fair attribution of transactions/revenue to each, in proportion to the number of touches contributed by each channel.
  • First Touch, Last Touch, 50-50 Reports - Attribution based on first touch, last touch, and an equal allocation of first and last touches, respectively.
  • Transaction Distribution Report - Shows the number of transactions that had one touch, two touches, etc, both by channel and as a total.
  • Transactions Report - List of each transaction and the contributing channels.
  • Touchlist Report - List of each transaction and the sequence of touches, in chronological order.
The time window for analysis, and how orders are attributed, can be adjusted in the reporting. The various reports are best explained through an example.

Example

Suppose 4 different visitors (A, B, C, D) interacted with various channels (Channel 1, 2, 3) and placed orders at specific points in time (T1, T2, T3, T4), as shown in the following table:

VisitorT1 T2 T3 T4
AChannel 3Order 1 ($2) Channel 1Order 2 ($4)
BChannel 1Channel 1----> Order 3 ($6)
CChannel 3Channel 1----> Order 4 ($8)
D  Channel 2Channel 1Order 5 ($10)

The All-Attribution report shows all transactions and all revenue in which each channel played a role, e.g. Channel 1 played a role in 4 orders (Orders 2, 3, 4, 5) totalling $28. For the above example, the report would appear as follows:

All Attribution Report
Channel TouchesTransactionsRevenue
Channel 15 4 $28
Channel 21 1 $10
Channel 33 3 $14
TOTAL 8 8 $52

The sums of the transaction and revenue columns are meaningless in this report, since each transaction is counted toward each contributing channel. The numbers against each channel are relevant, however, and can be taken to be total revenue supported by this channel, or conversely, how much revenue is at stake if this channel were to be deleted.

The Distributed Attribution report attributes transactions and revenue according to the proportion of touches, e.g. Channel 1 contributed half of the touches leading up to Order 5, and hence is apportioned 0.5 transactions and $5 for Order 5. The Distributed Attribution report would appear as follows:

Distributed Attribution Report
Channel TouchesTransactionsRevenue
Channel 15 2.5 $17
Channel 21 0.5 $5
Channel 33 2 $8
TOTAL 8 5 $30

Let's suppose that the time difference between T1 and T2 is 1 week, but T2, T3, T4 occur within 1 day, and suppose that we happen to know that 99% of purchase decisions are made within 6 days. Then it would make sense to analyse the data using a 6 day window, which would mean only one of the events at T1 would be counted - Order 1 occurs 6 days after T1 (Channel 3), all other orders occur 7 days after T1. So setting a 6 day attribution window would cause the reports to look as follows:

All Attribution Report, 6-day Attribution Window
Channel TouchesTransactionsRevenue
Channel 14 4 $28
Channel 21 1 $10
Channel 31 1 $2
TOTAL 6 6 $40
All Attribution Report, 6-day Attribution Window
Channel TouchesTransactionsRevenue
Channel 14 3.5 $23
Channel 21 0.5 $5
Channel 31 1 $2
TOTAL 6 5 $30

Note that Visitor A made two purchases. It's more than likely that Channel 3 was significant in influencing both Orders 1 and 2, so Channel 3 is counted toward both orders. However, suppose you have a belief that only channels seen directly leading up to any given sale are strong contributors. You can enable the 'single order model' to count in this way, which would lead to the following reports:

All Attribution Report, Single Order Model
Channel TouchesTransactionsRevenue
Channel 15 4 $28
Channel 21 1 $10
Channel 32 2 $10
TOTAL 8 7 $48
Distributed Attribution Report, Single Order Model
Channel TouchesTransactionsRevenue
Channel 15 3 $19
Channel 21 0.5 $5
Channel 32 1.5 $6
TOTAL 8 5 $30