Architecture
The Web SDK is composed of the following key components. It is designed to reflect best-in-breed security practices and to not interfere with your site and your customers. Read more about our approach to security.
Launcher
The Launcher is responsible for launching Rokt’s solution on a partner’s page. In itself, it has minimal logic - allowing a thin layer of integration with the partner and orchestrating iFrames on the partner's page. Due to the requirement of managing Rokt’s isolated iFrames the script needs to run on partner’s page outside of the isolative layer of iFrames. To minimize the risk associated with the script, it can be reviewed and versioned either by use of Subresource Integrity or by being hosted by a partner. Due to an optional versioning, the Launcher outsources all possible business logic to the Controller. This includes any communication with Rokt’s API. This ensures that changes to the file can be kept to a minimum.
Controller
The Controller iFrame holds the majority of the non-UI related business logic required to run Rokt’s solution. This allows us to minimize the complexity of Rokt Launchers to the bare minimum, ensuring the Controller is the only iFrame able to communicate with the Rokt backend.
Placement
The Placement iFrame is responsible for drawing and styling placements on partners' pages. Rokt’s solution may add multiple iFrames of this type to partner’s page, for example to be able to display a single modal (overlay) and an embedded placement. The Placement iFrame does not communicate with the Rokt API directly but expects configuration to be received from the Controller iFrame. To ensure configuration are not tampered with, the Placement and the Controller communicate through postMessage restricted to only their own domains.
Reporter
For edge case scenarios when the Controller iFrame fails to launch, the Reporter iFrame will send any errors to the Rokt backend.
The following diagram provides context on the components involved in a Rokt Web SDK integration.
