How does the qt parameter affect assigning transactions to user sessions?

From this guide, you'll learn the role of the qt parameter in creating links between transactions and user sessions.

If the delay between completing an order on a website and submitting the Measurement Protocol request exceeds a preset session timeout (it's 30 minutes by default), then it is essential to define the qt parameter in your request to Google Analytics and OWOX BI endpoint. Both the Google Analytics and OWOX BI algorithms determine to which session this particular transaction must be assigned based on the qt parameter value.

Next, we'll try to demonstrate the role of the qt parameter in creating links between transactions and user sessions. Let's see an example.

A user created three sessions during a single day with the next source/medium values:

  • google/cpc,
  • vk/cpc
  • google/organic

The user completed an order on a website during Session 2. Information about this transaction might be sent to Google Analytics and OWOX BI endpoint after the order completion.

scenario_0_en.png

Now let's see different scenarios of submitting the transaction hit via the Measurement Protocol.

Scenario 1. You submit the transaction hit with an undefined qt parameter right after the order completion or during the preset session timeout:

scenario_1_en.png

The transaction will be assigned to the right Session 2.

NoteIf the user returns to the website during the session timeout and before the request with the undefined qt is submitted, then a new session will start. And the transaction will be assigned to this new session. Let's see this case in detail:
scenario_1-1_en.png
- at 9:35 the user completed Session 2, and the 30-minute timing started.
- at 9:40 the user returned to the website and the new Session 5 started.
- at 9:45 the Measurement Protocol request with undefined qt was sent.
As a result, the analytics algorithm will assign the transaction to Session 5.

Scenario 2. You submit the transaction hit with the undefined qt parameter in 95 minutes after the order completion:

scenario_2_en.png

The transaction will be assigned to the wrong Session 3 which will be active at the moment of the request submission.

Scenario 3. You submit the transaction hit with qt=1800000 (the equivalent of 30 minutes) in 95 minutes after the order completion:

scenario_3_en.png

In this case, the transaction must be assigned to the session that was active 30 minutes before the request is submitted. Given that our user didn't have the session at that time, the analytics services will automatically create Session 4 for this transaction. As a result, the transaction will be assigned to the wrong Session 4.

Scenario 4. You submit the transaction hit with qt=2700000 (the equivalent of 45 minutes) in 45 minutes after the order completion:

scenario_1_en.png

In this case, the qt value reflects the exact delay between the order completion and the request submission. Therefore, the transaction will be assigned to the right Session 2.

 

To resume, if you know that there will be a delay between the order completion and the request submission, define the qt parameter in your request following these recommendations. If you already submit the qt parameter, ensure that its value is dynamic. The value in the queueTime field of the hit data table should reflect the actual delay for each particular transaction.

NoteIf the qt parameter is set to more than 4 hours, the hit won’t get to Google Analytics. Meanwhile, OWOX BI can associate the hit data with the right session if the hit is completed within 30 days. As a result, OWOX BI will collect more data than Google Analytics.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.