Home / Landing pages

a toolbox for UA experimentation.

At Pley, we helped game publishers bring their mobile games to the web. Porting the games was a fairly technical process, but we also had to help publishers acquire players, something they'd spent years optimizing for mobile and had considerably less experience doing in a browser.

Problem

Mobile UA teams had no web experience and couldn't adapt the player experience to targeted ads.

Approach

Found, defined and encoded the behaviours the landing page needed for their campaigns.

Outcome

Marketers ran their own variations without involving Pley every time, resulting in web ROAS on par with mobile.

We had quite a few questions about how people would behave. Should someone create an account before playing? Would they be more likely to stay if they could try the game first? What if they already played on mobile and wanted to continue their progress? And how long would someone wait for a game to load? We had built capabilities to support different approaches, although customers rarely experimented with them.

Usability testing had limited value for answering our acquisition questions. Someone participating in a usability test has agreed to spend time with the product. They'll probably wait for something to load, attempt to register, and try to understand an unfamiliar interface. Someone clicking an advertisement while browsing the web has made no such commitment and might leave after a few seconds.

We needed to run real acquisition campaigns to understand how these decisions affected conversion. Running those experiments was difficult, though. Changing the experience often required help from Pley's developers or other staff, which made testing several variations expensive and slow.

I'd previously designed and prototyped a landing-page template with configurable capabilities. It could prompt returning players to connect their accounts, allow new players to start immediately, or show a video while the game loaded.

In practice, customers often ran a campaign using the default experience, saw disappointing results, and concluded that web acquisition didn't work. There were several variables we could have tested before reaching that conclusion.

I spoke with user acquisition teams about how they configured and evaluated campaigns, including external partners working for larger publishers and people managing acquisition internally at smaller studios.

Their work revolved around campaigns, audiences, budgets, conversion rates, and acquisition costs. They were accustomed to running variations of a campaign and comparing the results, often across several audiences at once.

Our console was largely organized around technical capabilities, and some of the people responsible for campaigns had little reason to learn how those capabilities worked.

I considered building a landing-page editor where marketers could create and publish different experiences, but that would introduce another application for them to learn and maintain.

Campaign links were already central to their work. Each advertisement pointed to a destination URL, which they could distribute, track, and associate with an audience. I explored whether the URL could control the experience itself.

I prototyped an approach where URL parameters controlled how the web game behaved when a player arrived. The parameters were passed through to the playable game, with engineering extending the Web SDK to support the variables we wanted to experiment with.

A link could determine whether the game started automatically, whether players were prompted to connect an existing account, how much playtime they received before registration, and whether a video appeared during loading.

Some games had strong cinematics that appeared after the initial loading screen. We added an MP4 upload so the web player could show that video while the game loaded. A query parameter turned off the same video inside the game, so players wouldn't see it twice.

Some ads brought people into the game without converting them into registered or returning players, which meant they generated no revenue. We added a force auth parameter for retargeting campaigns aimed at people who had played and engaged before but hadn't returned. Without an email address from registration, we couldn't reach them by email. Retargeting gave us a way to bring them back and ask them to create an account.

We didn't know how long someone needed to play before they were invested enough to create an account and save their progress. It varied from game to game. A free play parameter let us test how much playtime to allow before asking for registration without shipping different builds or campaigns.

Some campaigns targeted a more mid-core gaming audience and highlighted that the game could be installed as a progressive web app. The prompt PWA parameter let us offer that option when the page loaded. The flag could also be used to increase playtime for retargeting idle authenticated players via email campaigns.

The same game build could support these different entry experiences without separate deployments. We could also distinguish existing mobile players from people encountering the game for the first time.

The game already had a healthy mobile player base, and our data showed that desktop players played longer and were more profitable. The publisher wanted to encourage existing players to play on both platforms. A campaign link could force the link-mobile-progress QR code, so those players could continue from their mobile progress instead of starting again.

I also designed a configuration interface in our console where marketers could select the behavior they wanted and generate a link for their campaigns. Each option had a short explanation of what it did and when it might be useful.

The teams began using the links to experiment with different entry experiences. Three common scenarios were separating returning mobile players from new players, showing a video during loading, and changing how long someone could play before registration.

They could now configure these variations without involving Pley every time, and we had a practical way to investigate how different entry experiences affected acquisition.

The broader acquisition work brought web campaigns close to the ROAS and customer acquisition cost benchmarks publishers were accustomed to on mobile. Publishers also continued investing in web campaigns as they became more familiar with the possibilities.

Campaign performance depended on several things beyond the landing page, including the game, audience, advertising creative, and acquisition strategy, so I can't isolate the contribution of URL configuration. We did, however, remove a recurring dependency on Pley's staff.

For the first three months, we ran “one build” across all games’ campaigns. Looking at our data combined with the UA teams’ campaign dashboards showed us which features a mobile game needed to convert and retain players on the web. It was also what led me to break each experiment into components that could be reassembled for different campaigns and games.

Looking back, I would have taken that learning further. We tracked individual campaigns, but we should also have tracked how combinations of capabilities affected conversion and retention across different campaign goals, audiences and game genres. New games could then have started with a campaign plan informed by previous results, bypassing the initial experimentation and closing the gap to revenue.

This was before AI was capable enough to help us analyze that data. Today, I would use it to look for patterns across campaigns and inform which combinations to test next.

I would have liked to stay with the feature through a second version, using those findings to help UA teams launch campaigns and start generating revenue sooner. I was needed elsewhere, so I didn't take it that far.