User interactions Preparation This step connects Froomle with user interaction data, letting the recommendation engine learn from behavioral and engagement data. Examples of user interactions that lead to an event are when a user opens an article detail page, clicks on a recommendation or purchases a product or subscription. We give a brief overview of integration approaches and available events. Main stakeholder Customer data/tracking owner (supported by integration developers). Results Decision made on which events to send. Event integration method selected. Privacy concerns clarified. Choose an event integration method The event contract is the same for both methods, but implementation ownership differs. Method Choose this when Start here 1. Frontend SDK (recommended for browser/web) You use declarative markup, JavaScript/TypeScript, or React and want the SDK to manage supported page and recommendation events. Event Tracking with the Frontend SDK 2. Manual / custom integration You send events from a backend, mobile app, custom browser implementation, Pub/Sub stream, or SFTP export. Manual Event Integration Manual delivery channels Events API: Use the Events API integration for real-time browser, mobile, or backend delivery. Pub/Sub: Use the Pub/Sub integration when Froomle has provisioned a streaming connection. SFTP: Use the SFTP integration for non-time-sensitive and historical events. Use Event Model and Tracking Contract to decide what each event means, independently of the chosen method. Decide which events to send Rollout sequencing matters: Implement page/business events first, such as page_visit, detail_pageview, and any applicable commerce or interaction events. Implement recommendation-attribution events such as impression and click_on_recommendation when the recommendation placements themselves exist. For overall go-live quality, both event groups matter, but they do not need to be implemented in the same development phase. The following table lists all available event types in the Froomle specification, organized by go-live priority and use case. Priority Event Description Must before recommendation placements go live page_visit Generic view event, not related to an item. Essential for analytics and typically implemented before recommendation placements go live. detail_pageview Sent when a user views a specific item’s detail page, essential for algorithm training and typically implemented before recommendation placements go live. Must for live recommendation placements impression Records that a user has seen a recommended item. This is required once recommendation placements are live. click_on_recommendation Tracks which (Froomle) recommendations are clicked. This is required whenever a live recommendation placement is clicked. Could have start_subscription Tracks when a user converts to a paid or registered subscription tier. item_interaction For actions like "save to wishlist," "like," or "share" on a specific item. Other available events user_interaction General interactions not tied to a specific catalog item. cancel_subscription Tracks churn events to help build better retention models. checkpoint A custom marker for reaching specific milestones in a user flow. add_to_cart Standard e-commerce event for adding items to the basket. remove_from_cart Tracks items removed from the basket for intent analysis. Batch processing events batch_open Recorded when a user opens an email or message containing batch recommendations. batch_click_on_recommendation A click originating from a batch-delivered module (e.g., e-mail). batch_impression Confirms the user viewed a batch-delivered placement. purchase The final conversion event, linking a user to the items they actually bought. For event semantics and shared payload rules, see Event Model and Tracking Contract. For exact API fields, see the Events API Reference. Next step Continue with Getting recommendations.