IHD-Experimentation Integration
Version Control
| Version | Date | Who | What |
|---|---|---|---|
| 0.1 | 29/01/26 | Saji Varghese & Patricia Nieto | Draft |
Document Overview
| Decision required | |
|---|---|
| Decision Outcome | |
| Owner | Saji Varghese & Patricia Nieto |
| Current Status | Draft |
| Decider(s) |
1. Context
We are looking to integrate our IHD flow with Experimentation (LES/Loop SDK), so that experiments can be run using our messaging platform.
Depending on the experiment a customer is a part of, this would enable us to do things like:
- Sending different message templates
- Having different message preferences (toast vs full screen)
2. Decision Driver
As per above.
3. Considered Options
Option 1: DES to LES calls
We include a LES client in DES Data Provider that we can use (using accountId, platform and product) to get the experiment id and variant.
It makes sense to call LES from DES since we already have other clients for CRO/CDS.
We then use the decision table in DES to send the appropriate message to the customer.
Benefits
- Simple implementation
Drawbacks
- Higher maintenance of the LES client
- Experiments will not be logged (exposed) unless we implement an LPS client to handle the logging (higher maintenance).
Option 2: Use Loop SDK
When adding a new experiment to the decision table manually, we will have the experimentID, which we can then use alongside the accountID, to call Loop SDK and get the variant. Note that if customer is not in the right Programme and Initiative (NA) we do not send anything, and the same happens for non-uki customers, so we would still use loop SDK but then not do anything with that information.
- We do a prevalidation and identify which experiment id applies given the RewardType (manually configured)
- Call Loop SDK to get customer's experiment variant
- We call Data provider for full customer context and experiment
- Return decision
Benefits
- Use loop SDK -> easier maintenance & register exposure through LPS (without needing to use BCG).
Drawbacks
- In case of decision not to send a message to a particular customer (due to NA Programme/Initiative or non-uki customer) we would
make an unnecessary call to loop SDK.
- This might result in an experiment being logged as shown to a customer (published to a kafka by LPS
for experiment exposures), even if we then can't use it (message is not sent).
Option 3: Use Loop SDK only as needed
- We would call Data Provider to get CRO/CDS input, which would give us the information we need to know if a message will be sent to a customer
- If message is to be sent to customer, then we would call Loop SDK to get the variant. Otherwise, no call is made.
- We would then call Data Provider again to get customer context.
- Return decision
Benefits
- No unnecessary calls to Loop SDK
- No unwanted experiment exposure logging
Drawbacks
- Two calls to DES Data Provider
