/
NUTRINTG Abandoned checkout service - audit and analysis

NUTRINTG Abandoned checkout service - audit and analysis

Overview

 

Every 1 hour Abandoned Checkout Service queries particular Shopify instance for new abandoned checkouts from the last hour (CRON job set up in properties - scheduler runs cdp-shopify-abandoned-checkout-producer flow).

Each configured Shopify shop is being queried for abandoned carts, for the previous 60 minutes (that is why it is run every 60 minutes).

Shopify query example:

https://enfashop-br.myshopify.com/admin/api/2021-04/checkouts.json?limit=250&updated_at_min=2021-06-28T20:00:00.00&updated_at_max=2021-06-29T23:59:59.000

Shopify returns abandoned carts between updated_at_min and updated_at_max. However, one must remember that shops exist in different time-zones. So when Mule calculates period to use, it calculates it related to Mule server time, not Shopify server time. As a result, some carts may appear in the feed after few hours.

Carts aggregated and send to queue. They are then processed by cdp-shopify-abandoned-checkout-consumer flow which enriches each abandoned cart with individualId from Epsilon (profile created in separate integration/service).

Once it is done, service creates a package with all new checkouts and sends it to Salesforce Journey through Journey Service.

 

Note: Hyho profile fetch is not included in the service as well as new CDP

New requirements

 

New requirement

Comment

Jira task

MoSCoW

Status

New requirement

Comment

Jira task

MoSCoW

Status

change Shopify query for abandoned checkouts from the value updated_at_min to the value created_at in abandoned checkout JSON

Basing on updated_at_min value in Shopify API query is a cause for discrepancies between Shopify and SFMC data.

Example:

This checkout was created at 12-04-2022 and updated at 21-05-2022.

As of today May 23, 2022 , this cart is visible in SFMC, but IMO it shouldn’t be there as the cart data is outdated

It also causes a lot of errors on a journey-service related to PK duplicated values:

Response from SFMC: {"message":"The event data contains duplicate value for an existing primary key. Please correct the event data and trygain.","errorcode": 30000,"documentation":""}

Error is thrown whenever client/app updates a cart in more than 1-hour period of time (so that the service tries to send the same cart data to the same journey)

https://rb-digital.atlassian.net/browse/EP-5992

 

S

TO do

adjust timezones to Shopify time specific to particular timezone

Shopify stores operate in different time-zones - when Mule calculates period to use, it calculates it related to Mule server time, not Shopify server time. As a result, some carts may appear in the feed after few hours. As of now, it is very difficult to track the delay because of other errors on the service

M

DONE

remove validation for cart_token field in SFMC

There are a lot of errors on a journey service related to cart_token = null. For unknown reasons this field is required by SFMC (I don’t see any use of it on this level, because each checkout has its own ID), so retrieved checkouts with cart_token = null will throw an error on a cdp-sfmc-journey-service:

According to Shopify documentation, cart_token = null for checkouts created using an offsite payment gateway like Mercado Pago in Mexico

If there is no need to usecart_token values in the journey, then probably it would be a good idea to remove this column from SFMC (or at least make it non-obligatory value)

S

TO do

skip searching for customer profile in Epsilon for CDS integrations

Example of error log from MW:

As a result, the service throws an error, because it looks for CDS profile in wrong database (CDP): - it always calls this endpoint:/api/v1/infrastructure/scripts/CustomProfileSearch/ → search id done in CDP (Epsilon) always: pmjn-pveapi.epsilonagilityloyalty.com


Note: a very few abandoned carts for CDS integrations are selectively thrown into the journey for profiles that were created in 2019-2020. According to @Małgorzata Mucha , customer data for Health brands was temporarily migrated to CDP

M

TO do

process abandoned cart only if the user accepted marketing

In BB requirements for abandoned checkout journey we can see the condition that the user has to accept marketing to receive abandoned checkout communication:

I noticed that this criterion is misleading, because to journey flow carts whose users didn't accept marketing. Example:

This user in Shopify has indeed has a flag buyer_accepts_marketing = true for this checkout, but he didn’t agree for marketing communication at all:

Solution: to be compliant the entry criteria should be based on accepts_marketing flag in customer node (our source of truth for marketing communication) instead of buyer_accepts_marketing

S

TO do

limit query for abandoned carts in Shopify to maximum (250 carts)

there is a bug that limits query in Shopify to 2 only → it should be set up to maximum (250), checkouts.json?limit=250

FIXED

M

DONE

replace Shopify API access with custom app (instead of private app)

it is not necessary as soon as Shopify API access for our service via Private app is working correctly, but keep in mind that Shopify deprecated private apps in the begging of 2022 and we don’t know if they are going to maintain private apps in near future

C

TO do

add Hyho to abandoned checkouts data flow

it requires exposed REST endpoint for SC profile fetch as well as a decision if whether this goal is worth the development work required. Might be required for example for: https://rb-digital.atlassian.net/browse/EP-5527

C

TO do

References

  • SFMC documentation for BB project - abandoned checkout journeys as a part of it