The question every publisher asks first is whether the game can live inside their site rather than beside it. The answer is yes, by three different routes, and the choice between them is usually made on the wrong criterion.<\/p>\n
Most buyers choose on integration effort. The right criterion is what each route does to your analytics, your search authority and your sharing loop, because those three decide whether the game grows.<\/p>\n
A JavaScript component.<\/strong> The game renders inside your page as part of your document. It inherits your styling, your analytics see it as your site, and your consent framework governs it. This is the cleanest route and the one to take wherever your platform allows a script or framework component.<\/p>\n A scoped iframe.<\/strong> The game runs in its own document inside a frame on your page. Your header, navigation, footer and branding surround it, and responsive behaviour is built to your breakpoints. This is the route where the host platform is locked down and will not accept third-party scripts.<\/p>\n A native component.<\/strong> For a React, Next or similar front end, a component your team imports and configures. Most control, most involvement from your developers.<\/p>\n An iframe is the easiest thing to sell and the most expensive thing to live with, and the cost is not technical. It is growth.<\/p>\n Analytics attribution breaks first.<\/strong> The frame is a separate browsing context. Your existing tags see a page view and then nothing – no interactions, no funnel, no attribution back to the campaign that brought the user. You can bridge it with cross-frame messaging, but that is work, and it usually gets discovered after the first month’s reporting looks wrong.<\/p>\n Sharing breaks second, and it matters more.<\/strong> The single strongest growth mechanic in a season-long game is a private league invite. One person creates a league and brings colleagues and friends, and every one of them registers on your property. That loop depends on a link that opens directly on the join-league screen with the league already identified.<\/p>\n Inside an iframe, the address bar shows the parent page. The frame’s internal state is not in the URL, so the link a manager copies does not carry the league. They end up sending “go to this page, then click leagues, then search for mine,” and most of the people they send it to do not arrive. The invite loop is the cheapest acquisition channel a fantasy game has, and an iframe quietly turns it off.<\/strong><\/p>\n Search authority goes third.<\/strong> Content inside a frame does not accrue to your domain, and neither does anything hosted on a vendor’s domain or a separate subdomain. If the game is a section of your site, the pages it generates – competition rules, scoring explanations, league pages – build authority for you. If it sits somewhere else, they build it for somebody else, or for nobody.<\/p>\n None of this makes the iframe wrong. Where a content management system will not accept a script, it is the correct answer, and the constraints are manageable if you know about them at scoping. They are not manageable if you find out in November.<\/p>\n The largest single change to participation is not the embedding method. It is whether your users have to register at all.<\/p>\n If your audience is already logged in to your site, the game should receive an authenticated token and let them in. No registration form, no second password, no drop-off at the exact moment their interest is highest. In our experience this is the single biggest lever on participation of anything in this list.<\/p>\n The mechanics differ by route. A component in your document can read your session directly. An iframe needs a token passed across the frame boundary and validated on the game side, which works but adds a handshake and a place for it to fail.<\/p>\n Two things to settle at scoping rather than during integration: what identifier the token carries, and what happens when a session expires mid-gameweek while someone is making a transfer.<\/p>\n Fantasy load is not steady. Load peaks in the hour before each deadline, and the scoring engine is what buckles first if the architecture is wrong.<\/p>\n The relevant point for an embedding decision: the game’s peak should not become your site’s peak.<\/strong> Player-facing application, scoring engine and data layer scale independently of each other and of your site, with static assets served from a CDN and the admin panel isolated from the player-facing stack. Your page serves the component; the component talks to infrastructure sized for match day.<\/p>\n We have held 200K peak (150K sustained) concurrent players at sub-40ms, in IPL cricket. The reason that number belongs in an embedding conversation rather than an architecture one is that it is what stands between a busy Saturday and your own homepage going down alongside the game.<\/p>\n A frequently missed consequence, and it works in your favour.<\/p>\n When the game runs inside your site, your consent management platform governs it, your cookie policy covers it, and end-user data sits under your existing privacy notice. You are the controller. The platform vendor is the processor.<\/p>\n When it sits on a vendor’s domain, users cross a boundary they can see, they meet a second consent banner, and the controller question becomes something you have to explain in a privacy notice rather than something obvious. That is not fatal, but a UK or European procurement review will ask about it, and the embedded answer is materially simpler to give.<\/p>\n Everything above concerns the web. On mobile the same three-way choice appears as a webview, an embedded component, or a native build, and the tradeoffs run in the same direction: a webview is fastest to ship and weakest on session handling and deep links, a native component costs more and behaves properly.<\/p>\n The decision worth making early is whether an invite link opens the app for a user who has it installed. If it does not, the invite loop that already suffers inside an iframe suffers again on mobile, and mobile is where most invites are opened.<\/p>\n Four questions, and they take ten minutes.<\/p>\n What is your site built on, and will it host a third-party script or framework component? Do you have single sign-on, and can it issue a token to a component? Where does your analytics stack live, and what needs to see the game’s events? And is there a mobile app in scope, or web only?<\/p>\n\n\n
\n \n<\/th>\n JavaScript component<\/th>\n Scoped iframe<\/th>\n Native component<\/th>\n<\/tr>\n<\/thead>\n \n Lives on your domain<\/td>\n Yes<\/td>\n Frame content does not<\/td>\n Yes<\/td>\n<\/tr>\n \n Inherits your CSS<\/td>\n Yes<\/td>\n No – styled to match<\/td>\n Yes<\/td>\n<\/tr>\n \n Your analytics see it as your site<\/td>\n Yes<\/td>\n Partially, and it degrades<\/td>\n Yes<\/td>\n<\/tr>\n \n Consent and cookies governed by you<\/td>\n Yes<\/td>\n Split across two contexts<\/td>\n Yes<\/td>\n<\/tr>\n \n Deep links to game state<\/td>\n Yes<\/td>\n Constrained<\/td>\n Yes<\/td>\n<\/tr>\n \n Search engines index the content<\/td>\n Yes<\/td>\n No<\/td>\n Yes<\/td>\n<\/tr>\n \n Your developers’ effort<\/td>\n Low<\/td>\n Lowest<\/td>\n Highest<\/td>\n<\/tr>\n \n Where it applies<\/td>\n Most sites<\/td>\n Locked-down platforms<\/td>\n React, Next, similar<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The iframe problem nobody raises until month two<\/h2>\n
Single sign-on is the biggest lever, and it is an embedding decision<\/h2>\n
Match-day load, and what it does to your infrastructure<\/h2>\n
Data protection improves when the game is on your domain<\/h2>\n
The mobile app<\/h2>\n
What we would ask before recommending a route<\/h2>\n