Getting Recommendations Froomle offers multiple modes for delivering personalization, ranging from real-time website modules to scheduled newsletter exports. Choosing the right delivery mode ensures that your recommendations reach users through the most effective channel. This step assumes item synchronization is already in place and page/business event tracking has been designed first. For the full onboarding order, see Getting Started. Integration Lifecycle The transition from goal setting to live recommendations follows a standard sequence: 1. Preparation Stakeholder: Customer integration developer (frontend/backend). Requirements: Modules and placements defined during onboarding. Prerequisites: Item catalog sync running and validated; page/business event tracking contract agreed. Access: Environments and credentials active for test and production. 2. Modules Modules are the building blocks of any Froomle integration. Each module represents a distinct placement in your user experience—such as a "Recommended for you" section on the home page—and maps to a fit-for-purpose backend ensemble that defines its underlying behavior. Before implementation, you’ll select the modules that best align with your specific business goals. For more details on defining modules, see Modules and placements. For specialized content patterns (e.g., "Trending", "Similar Articles"), see our News modules library. 3. Delivery Modes Mode Use Case Implementation Real-time API: Recommended Items List Website modules, mobile app carousels, and instant results. Recommendation Requests Real-time API: Reranking Personalizing a pre-existing list of articles or search results. Smart Sorting Batch & Newsletter Scheduled email campaigns and large-scale precomputed exports. Batch Recommendations Push & Audience Personalized notifications and segment-based targeting. Audience API Personalized Search Retrieving items based on a search query, with personalized relevance ranking. Search API 4. Build the request contract For each application of the Froomle engine, you must establish a Request Contract. This includes: Placement: Defining the module and list names, page_type and channels for which you want to receive recommendations. Context: Providing additional fields such as context_item or context_category to anchor the results. Filters and constraints: Applying static or dynamic filters to the recommendation results. See Filters and Constraints. User Identification: Supplying user identifiers such as user_id or device_id, to enable personalized results. See User identity and consent. 5. Render and Validate Implement response handling and render logic. If a placement is benchmarked, choose the benchmark ownership model here as part of the recommendation implementation. Validate that the response size and latency fit your performance budget and that empty responses degrade gracefully. For web integrations, a supported advanced pattern is to fetch recommendations on your backend while still using the browser SDK for event tracking. If you choose that shape, preserve the recommendation attribution metadata in the rendered markup. See Advanced Hybrid Pattern: Backend-Fetched Recommendations + SDK Event Tracking. 6. Feedback Loop Track recommendation attribution events such as impression or click_on_recommendation events for every module. This closes the loop for the rendered placement. Core page/business events such as page_visit and detail_pageview should already be in place before this step. See User interactions. Advanced Considerations SEO and AMP For SEO-sensitive pages, avoid client-only rendering that hides recommendations from crawlers. If recommendations must be crawlable, render them server-side or use a hybrid approach. For AMP pages, use a compatible integration pattern and limit heavy client-side scripts to keep AMP validation and performance intact. Next step Continue with Monitoring performance and quality assurance.