This guide explains how to send Ravelin data about guest checkout.
On this page:For most of Ravelin’s merchant-related products, the customerId is the key identifier as many of our products focus on analysing the behaviour of an individual.
This guide explains what identifier to use as the Ravelin customerId for guest checkouts.
The guiding principle for guest checkout is that all orders placed by the same individual should be associated with the same customer profile in Ravelin. This is useful for visibility within the Ravelin dashboard and it is important for the performance of the machine learning models.
In all cases regardless of implementation, we ask for a clear indication of the account type in use when the order is being placed. This can be supplied on the /v2/checkout requests in the accountType field, on the customer object (for general account status) and/or on the order object (to show whether the specific order used guest checkout).
You may already generate a unique identifier for an account in your backend systems regardless of whether an order was placed by a registered account or guest checkout was used.
This is usually accompanied by a restriction that enforces a 1:1 mapping of email address to this unique identifier. If you do allow the email address associated with a registered account to be changed, the new email address will need to be one that is not already associated with an account. The unique identifier used as the Ravelin customerId will remain the same.
This is the best case scenario for Ravelin. It means all orders for that account, including guest checkout orders, will appear under the same customer profile and the purchase history can be considered by the machine learning model.
This option relies on being able to generate a permanent (or semi-permanent) identifier to be used as the customerId for guest checkout, that will persist over multiple orders from the individual. This could relate to some sort of session ID or cookie.
If you are unable to generate something that is persistent enough to allow grouping of multiple orders under the one profile, then please consider one of the other options described instead. To help decide, we suggest considering the expected lifetime of the identifier, and how often customers normally order from your site. In general, Ravelin would like to avoid seeing a new profile generated for each guest checkout order.
For registered accounts, please continue to use whatever persistent unique identifier is available in your systems.
Convert the email address supplied by the customer to lowercase and send that to Ravelin as the customerId for any guest checkout orders.
The customerId field is case-sensitive, therefore the email address needs to be converted to lowercase in order to avoid multiple profiles being set up in Ravelin when an email address comes through with different casing.
For registered accounts, we recommend that you continue to use whatever persistent unique identifier is available in your systems. This does mean that registered and guest checkout orders that relate to the same email address will appear under 2 different profiles.
Consider the quality of the email address data that you receive before selecting this option. The guest checkout flow is usually designed to collect minimal information with low friction, so email address data is unlikely to be verified.
This option suggests taking the deviceId that is already being sent to Ravelin, and setting that as the Ravelin customerId for guest checkout orders.
A disadvantage of this approach is that the deviceId may not always be persistent, potentially splitting orders over multiple profiles in the Ravelin dashboard and resulting in a loss of historic purchase history for the machine learning models. Also, if a device is shared, all orders will be captured under the same Ravelin profile even if orders are placed by different people.
If there are issues with reliably supplying the deviceId in all cases, then this may not be the best solution to use.
For registered accounts, please continue to use whatever persistent unique identifier is available in your systems.
The identifier used as the customerId in Ravelin is critical to a good quality
integration, and must be unique within your environment (e.g. unique across all markets).
If you are already integrated with Ravelin, and your business is now adding support for guest checkout, it is important to consider how this may impact your existing traffic.
You can discuss your options with the Integrations team so you can decide on the best approach for your business.
Some of the additional questions we are likely to ask are included below for reference:
customerId?Was this page helpful?