Tracking Products

We use two different methods in tandem to track the current product in your app. In addition, we use a separate method to track the products that have been added to the cart.

trackProduct

The first method we use, trackProduct, tells us about the current product as a Product. It tells us all the possible variations of the product. It is important that you tell us about every variation that is actively available. We use this list as the source data for the setCurrentProduct method, but the Granify Brain will also use this list to match up to any specific specials or hot items.

In addition to the list of possible variations, you also need to provide a CurrentProductCarterCallback. This simple closure will be called from campaigns that offer an “Add To Cart” button. This button is intended to simulate the “Add To Cart” functionality of the product page itself. The callback should add the current product to the cart, using the currently selected options, exactly as if the shopper had clicked the button on the page itself. If the behavior of your app would be to collect additional information before actually adding the product to the cart (eg: if sizes or colors have not been selected yet), then this method should initiate the same behavior.

see Granify.trackProduct(products:currentProductCarterCallback:) for more details

setCurrentProduct

The second method, setCurrentProduct, tells us which of the variations of the product is currently selected. The method only accepts strings for the sku and productId parameters because these are used to simply lookup the variation from the list supplied in the last trackProduct call. The sku and productId must match exactly one of those Products.

This method must be called immediately after the trackProduct method is called. This will tell us which variation of the product is currently selected. This would normally be the default item, but there may be some logic to choose a default for each shopper, or the shopper may be returning to a previous choice.

In addition, every time a shopper changes their selection, you must call this method again identifying the new sku as the new current variation.

see Granify.setCurrentProduct(sku:productId:) for more details

trackCart

If your app has access to the full contents of the cart, you should use the trackCart method to keep Granify up-to-date about your cart details. This is the preferred method, so you should use it unless you cannot.

Whenever a product is added to the shopper’s cart, or the cart is modified in any other way, you must call trackCart. You should also call trackCart when the app starts, and whenever the app returns after losing focus for any reason. Pass the complete contents of the cart with every call, even if the cart is empty.

It is not absolutely required that you use the same referenced Product object for the cart that you did for the trackProduct call, but the information in the object must be the same. It is especially important that both the productId and the sku are identical for the same product.

see Granify.trackCart(items:) for more details.

trackCartChange

If your app does not have access to the full contents of the app, but interacts with an API in some manner to request changes to the cart (eg: your app handles the cart using a separate site in a webview, but you add products to the cart using an API call), you should use the trackCartChange methods. The trackCart method will always take precedence over trackCartChange, so if you use both in the same app, you risk losing the changes recorded with trackCartChange. You should always use only either trackCart calls or trackCartChange calls in one app, but never a mixture of both.

There are two forms of the trackCartChange method; one that allows you to add new items, and one to remove them. Use the Granify.trackCartChange(add:quantity:) method to add a new item to the cart, or to increase the quantity of the item, if it is already in the cart. Use the Granify.trackCartChange(remove:quantity:) method to reduce the quantity of an existing item in the cart, or to remove it completely.

see Granify.trackCartChange(add:quantity:) and Granify.trackCartChange(remove:quantity:) for more details.

Which Cart Tracking Method Should I Use?

In most cases, an app will have full access to the contents of the cart. The app will either manage the cart contents itself, or the cart will be stored in the cloud somewhere, but the app will download the entire contents of the cart, and keep it’s internal version synchronised with the external version. For both of these cases, you should use trackCart to notify Granify of the cart details. trackCart is our preferred and recommended method.

However, some apps split control of their shopper journey into multiple, clearly separated parts. One might know all about the products and categorisations, but nothing of the cart, while the other will know all about the cart, and allow the shopper to checkout, etc, but will know nothing about the product catalogue. For example, an app might be designed with the product catalogue rendered as an iOS native app, with the cart and checkout process handled by a website running in a webview inside the app. In this case, the native product catalogue portion of the app will not have any access to the cart, but might add products to the cart using an API call. This app would need to notify Granify that a change has happened to the cart, and may use the appropriate trackCartChange method to do so.

App Suspension

When the shopper returns after hiding or suspending the app, or returns after idling for long periods of time (greater than 30 minutes), communication with Granify’s servers may have ceased. In this case the shopping session has become inactive and a new session will be created.

When a new session starts, the SDK will re-send its most recent cached information about the shopper (i.e. shopper id, cart, and wish list information) to the server to initialize the new session’s data. It is important however to call any of the Granify session tracking functions with updated information if it may have been changed while the app was idle or suspended. For example, if a shopper’s cart is synced with their account across multiple devices, changes made on other devices will require Granify.trackCart(...) to be called when the app becomes aware of the change to the cart.

Information specific to the shopper’s current session will not be cached and automatically sent to Granify’s servers on app resume. Therefore, it is important to call the trackProduct, and setCurrentProduct explicitly with the information for the app view that loads when resuming from a suspended state (after calling trackPageView, of course).