Transactions tracking

1. Situation analysis and issues encountered

newsletter-tag-transaction__1_.jpg

1.1 Reminder of the functioning of the tracking

Conversions are sent to iAdvize using the JavaScript conversion tag installed on your order confirmation or lead pages.

The order details with its price and unique transaction ID are sent to iAdvize. You can thereafter see how many conversations converted into a transaction/lead and pay ibbü experts when the performance-based model applies. 

The "triggering of the JavaScript tag" method isn't foolproof and some transactions may not be sent to iAdvize.
Several factors such as:

  • Unstable internet connection from the visitors' side
  • instabilities of our servers at the time of conversion
  • an order confirmation page that has been closed before the iAdvize tag could completely run can account for such losses of transaction information

We, therefore, worked on this topic to improve our transaction tag and limit the loss of information. This guarantees a fair payment of the ibbü experts and allows our customers to measure the iAdvize conversation service at fair value.

1.2 Kind of improvements

We developed a system that sends again a transaction if it hasn't been properly saved. Transactions can now be tracked even if the JavaScript tag has already been triggered.

We also paired VUIDs with transaction IDs in order to delete errors whenever two transactions with the same IDs, but a with a different VUID, are tracked (that is to say, two different persons who generate a transaction each).

2. Which respondent gets the transaction for a conversation? 

Remuneration related to asynchronous conversations will always be allocated to the respondent (pro operator or ibbü expert) who last exchanged with visitors before they made a purchase. The timing of the closing of the conversation is not important.

i.e 

    • Respondent A <> Visitor
    • Respondent A snoozes
    • Respondent B <> Visitor
    • Respondent B snoozes
    • Transaction
    • Respondent C <> Visitor
    • Closing

    => Operator B gets the transaction

 

i.e 

  • Expert A <> Visitor
  • Expert A snoozes
  • Expert A <> Visitor
  • Expert A forwards
  • Expert B <> Visitor
  • Expert B snoozes
  • Transaction
  • Expert B <> Visitor
  • Closing

     => Expert B gets the transaction

 

For ibbü experts on conversation based missions (and not at the transaction):
The transaction is allocated at the conversation end.
If the ibbü expert snoozes the conversation, he/she will not get paid yet as the conversation is still considered as in progress. 
Another example: for a 48-hour transaction delay on the site. The expert takes the conversation on a Monday, sends a message immediately, then pauses (snooze) the conversation for 1 week without adding any message. If a transaction takes place on Thursday, will it be attributed to him?

=> No, there is no attribution of the transaction, if there is more than 48h between the last message of the expert (or the agent) and the transaction of the visitor.