When a customer places a call to a call center, the call-tracking application sends us an event containing key information about the call.

The event is normally one of our vertical-specific transaction events:

• ecBasketTransactionSummary
• trPackageTransactionSummary
• fiBasketTransactionSummary

Once the data has has been logged by the call center team, either at the start or end of the call, a call-back script in initiated.

TIP: The call-tracking application will emit a transaction event for the call. In this way, we can treat calls as conversions. This is especially relevant for non-transactional sites.

The event includes the client's tracking id, the Qubit context_id, and additional ancillary information:

• ts - unix timestamp when the event was received
• url - the url of the page the customer was viewing when the event was received
• transaction.id - unique transaction Id, which could be the Id of an order taken over the phone. Where this is the case, we will also populate the event with a basket total

Example:

{
   "events": [{
     "context": {
       "id": "test-integration-property"
     },
     "meta": {
       "type": "ecBasketTransactionSummary",
       "ts": 1516810598,
       "url": "http://example.com/page",
       "source": "Respose-test-integration@1.0.0"
     },
     "basket": {
       "total": {
         "value": 9.99,
         "currency": "GBP"
       }
     },
     "transaction": {
       "id": "09890809"
     }
   }]
 }

Infinity send us events only for calls that are matched to a Qubit context_id; these are calls made when the visitor is online.

responsetap send both those and events where they have not identified the user. These usually occur because the call has been made later and the phone number, having expired, does not match their current data. responsetap refer to these events as offline.

From some customers, we receive further unusable offline events from responsetap that are typically the result of search engine adverts that are not related to user sessions on the customer's site. For offline calls, responsetap populate the context_id field with their visitor Id that currently starts with either gbr0 or clarity.

Our processing enriches each event with further context information and stores it in the relevant TransactionSummary table. This scheme enables us to match the event's data about the call with our record of the view on which the call occurred and to integrate with our wider data on the user's activity, in particular to record calls as conversions or goals.

INFO: Typically between 67% and 96% of call events are successfully enriched and matched with user activity.