ScandiPWA Setup Specifics

What is ScandiPWA

Single Page Progressive Web Application with persistent cacheable GraphQL support BE

PWA - reduces dependency on a server, thus, making the website app-alike in that sense.

Requirements:

Manifest -> “document” that contains app data (image names, icons, etc)
Service Workers -> proxy between client & server, which, can cache requests to a server

SPA - improves UX

Dynamic content update on one page (usually by JS)

Client-side rerendering -> consequence of SPA

GraphQL - data query and manipulation language for more granular data requests

Why Do We Have the Following Stack

PWA

1. One codebase for all platforms - web, iOS, Android

2. Could go offline in browsers

As a bonus - Gives us control on caching algorithms

SPA

1. Allows making the website feel like a native application

2. Reduces data load, thus, giving faster page loads (as we do not request the full page from the server)

Works well with PWAs caching -> allows reducing data loads, even more, thus making the page faster

GraphQL

1. Request only data that we really need (thus making it faster once again)
a. Lowers data loads as we request less data
b. Faster data processing/rendering as we request less data
2. Developers suggest that it is more convenient to use as you have just one data source

The drawback is that the GraphQL requests cannot be hashed straight away, therefore, we deploy additional measures as:

Making queries persistent

GTM & dataLayer

As usually - we proceed with the dataLayer & GTM for our lovely ScandiPWA.

The setup should contain the following parts:

PWA GTM module

PWA ITP module
PWA HTTP protocol order tracking module

Why such a setup:

As always - the most flexible and efficient setup. Given the fact that page load happens once per session -> no need to reload your init
snippets
In addition to that - GTM has auto event listeners which capture page views in PWA
ITP module now is a good-to-have for projects to improve the tracking capabilities of Safari browsers
HTTP protocol module for order tracking ensurest that orders are tracked correctly, which, is getting harder to do with regular methods
(for PWA)
Drawbacks

Both GTM & Tracking scripts are JS-based, which can result in the high load on the lower-tier devices if you try to load scripts asap as at the
same time PWA will be rendered on the device

Issues that you will encounter

PWA website FrontEnd is JS-based

This could impact some of the scripts that you are using, in the example:

Screen recorders
Heatmaps
A/B testing tools

Most likely, for those, you will need to use a specific version of the script that works with JS-based FrontEnd

TO-DOs

Ensure in advance - which tracking solutions client is using so that we could provide an alternative setup in case if tracking scripts do not
support ReactJS

No reloads

Which means that:

You cannot use the pageview triggers as you usually do as, otherwise, tags will trigger once per session
dataLayer values are stacked throughout the session

TO-DOs

Use history change trigger to fire page view tag each time the URL changes OR "general" dataLayer.push event (history change trigger
should be more reliable tho)
Use "version 1" for the dataLayer variables e.g. for "ecommerce"

NOTE:

Page loading speed analytics could not be done by a built-in functionality.

Client-side rendering

This one appeared not to be a big deal either - we did introduce a slight delay of 0.5 seconds for the GTM load. Delay allows both PWA theme
and GTM to load faster as otherwise they would if they would be loaded ASAP, this did not result in any significant changes in data quality. Time
of delay was determined by trial and error method as it largely depends on your server capacities

TO-DOs

Test if you need to introduce a delay for GTM load and if so test how long the delay should be

Asynchronous data loading

In short - it could happen that due to async data loading you could have a time when page URL & Page Title do not match, and if Google
Analytics records data at that time - you can get:

Increase in unique pageviews - as unique page view is defined as a unique combination of URL & title
increase in the number of sessions - as GA uses document.location to identify sessions

The issue is not critical and you simply need to put some effort into QA this scenario. In addition to that, if you are using GraphQL for data
transfer, and are pulling data from multiple sources - it could be that you’ll need to set up “awaiting” of data arrival for some of the scripts

TO-DOs

QA extensively match between page title & URL

Communicate with developers if you need to wait for some data to arrive for dataLayer.push

Additionally
In case if you need some "exotic" data that we do not use often in our setups approve with developers if they can get you those data, as it could
be that getting additional data will require modification to the PWA core, which will take significant efforts.

Extensive Caching

From time to time it has occurred that the PWA theme did cache our tracking scripts, therefore, when scripts were executed they were in the
HTML instead of JS, thus, do not forget to add ALL of your tracking scripts to the whitelist from caching.

TO-DOs:

Provide developers with the list of scripts to be excluded from caching e.g. "https://www.googletagmanager.com/"

Standalone Display Mode

Most likely you would like to know how many users do add your app to the home screen -> you can identify those by adding custom JS variable
to check if the display mode is standalone

TO-DOs:

Add the CJS variable as a custom dimension for the standalone mode check

Analysis

For the analysis, the only thing that you should need to keep in mind is that you cannot trust the page loading time data