1. Situation analysis and issues encountered

1.1 Reminder of the functioning of the tracking

Conversions are sent to iAdvize using the JavaScript transaction 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?

2.1. Last respondent principle

Remuneration related to asynchronous conversations will always be allocated to the last respondent (pro operator, ibbü expert or bot) if a response has been given within 48 hours before the transaction. This delay can be personalised at your request.
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

2.2 ibbü expert specificity

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.

2.3. Read conversations that have generated transactions

In the Sales report, filter the transactions to see the exact amounts and the contact ID corresponding to the sales. At the same time, open a new tab on the Conversation report; thanks to the contact ID, you'll be able to view the conversation that generated the sale.