User Journey Temporary Keys

Often in a user journey through your website, a user steps through several pages and only on completion of an activity gets an ID. e.g. for an e-commerce website when checking out, a user may go through a basket page, start checkout, payment, confirm details and only on the order confirmed page do they get an order id.

In order to join this journey up the Intilery JavaScript API provides a method to create a temporary key at the start of the journey, which can then be replaced with the final key from your system should the customer complete the journey.

The temporary key provides a key throughout the journey in place of the key you would use to identify the 'order' in your system. On the last step when you generate your 'order ID', you pass both your key and the temporary key back to Intilery to enable the swap.

To define a key use the following code before sending any itq events that use the key:

_itq.push(["_callIntileryFunction", "registerKey", 
    ["<key name>", ["<event actions to reset key>"],
     <session only>, <key generation function>]]); 

e.g. to register a key for a booking that will last across sessions, with a new key being generated after event action make booking use:

_itq.push(["_callIntileryFunction", "registerKey", ["booking", ["make booking"]]]);

you can optionally set the key to last only for a session, and you may provide your own function to generate a key.

To pass a key value as part of an event, as the itq methods are called asynchronously, you must set the event value to a function that returns either INTILERY.getKey or INTILERY.getNewKey, otherwise these functions will execute before the key is registered:

"Booking.ID": function() { return INTILERY.getKey("booking"); }

If you use INTILERY.getNewKey, then that will force a new key to be generated regardless of how the key was registered.

If you do not call registerKey, but use getNewKey, then the Intilery API will generate a key that can be used with getKey, however getKey will not work unless registerKey or getNewKey has been called first.


Consider the following series of events which pertain to a booking. When the booking is made by the final event, it will be given the key that our system uses to store and track the event. For the previous events, it will be assigned a temporary key generated by our system for tracking.

Event 1 - Start Booking:

_itq.push(["_trackUserEvent", "start booking",
	{"ID":function() { return INTILERY.getNewKey("booking"); },
     "Price Per Person": "20",
     "Nights": "2"
"Start Booking"

This is the first event in the sequence and the Booking.ID is assigned a temporary key by calling the INTILERY.getNewKey("booking") function. This will create a new key and store it against the name "booking".

Event 2 - Select Flight:

_itq.push(["_trackUserEvent", "select flight",
	    {"ID":function() { return INTILERY.getKey("booking"); },
		"Departure Date": Date,
		"Destination Airport": "String Value",
	"Select Flight"

In this second event, the user is adding information to their booking, but there is still not a permanent key for it, so it is referenced by calling the INTILERY.getKey("booking") function, which retrieves the key associated with "booking" that was created in the last event.

Event 3 - Make Booking:

_itq.push(["_trackUserEvent", "make booking",	
       "Booking._ID":function() { return INTILERY.getKey("booking"); }
"Make Booking"

In the last event, the actual booking ID ("someBookingID") will be available and assigned to the event, while the temporary key will be assigned to "Booking._ID", thus linking the final booking ID with the temporary key used in all the other events. In this way, all events pertaining to this booking can be easily found.

Still need help? Contact Us Contact Us