Architecture
The Web SDK is composed of four key components. It is designed to reflect best-in-class security practices and not to interfere with your site or your customer experience. Read more about our approach to security.
Launcher
The launcher is responsible for launching Rokt’s solution on a partner’s page. The launcher 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 isolated layer of iframes. To minimize the risk associated with the script, it can be reviewed and versioned either by use of Subresource Integrity (SRI) 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 the partner’s page, for example 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 is 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 sends any errors to the Rokt backend.
The following diagram provides context on the components involved in a Rokt Web SDK integration.
