The share button in a daily game: rates from five games

relaydle is a directory and cross-promotion rail, and this data comes from its own founder's games, not from the directory itself, so read the numbers as one developer's account, not a market survey. All five games use the same underlying share kit, so the differences below are deliberate choices about the button, not different code stacks.

What share rate do these five games actually get?

Share rate here means winning sessions that also fired a share event, in Umami, all-time through 2026-09-25 (each game's own launch date is in the table). Event names differ per game: DailyFoot counts share and share_intent, DailyMetro and Le bon rang count share and share_open, Geopolitix and DailyGeo count share (DailyGeo also share_result).

What do the highest-rate share buttons do differently?

The two highest-rate games, DailyFoot and DailyMetro, both put the phone's own share sheet (the navigator.share API) on the primary button, so sending a result is one tap on a sheet that already lists the player's own contacts and apps. The two lowest-rate games, Geopolitix and DailyGeo, deliberately built the primary button to open a popover menu of named destinations (X, WhatsApp, Instagram, Messenger, Facebook, copy) instead, on the reasoning that the whole family of games should "share one way of posting a result," per that shared component's own code comment. Le bon rang sits in the middle and switched from menu-first to native-first mid-run; its own code comment records the menu's old numbers as roughly 45 openings against a thousand copies before the native sheet became the default on touch devices.

Five games is not enough to prove the native sheet causes a higher rate. The games differ in audience (football fans, transit riders, geography players), in how long a session runs before the win screen, and in what the shared text says, and the event names are not identical across games (see above), so the rates are directionally comparable, not a controlled test. What the code does show plainly is that a menu of destinations adds a step between the tap and the send that the native sheet skips.

How do you build a share button like this?

The core is small. A few lines, each doable in a single line of code:

• Try the OS sheet first: if (navigator.share) await navigator.share({ text }) opens it in one tap on any device that supports it.
• Fall back to the clipboard when there's no sheet: await navigator.clipboard.writeText(text), then show a "Copied" message for a couple of seconds.
• Add one-tap channel buttons next to it for the apps a menu would otherwise bury: WhatsApp opens with window.open('https://wa.me/?text=' + encodeURIComponent(text)), X with window.open('https://x.com/intent/post?text=' + encodeURIComponent(text)).
• Track the open and the send as two separate events, because a dismissed OS sheet looks identical to a completed one from the code's side: fire one event when the sheet or menu opens, and count a share only once a channel actually confirms (the OS sheet's own promise resolving is the one exception, since it can't tell you which app was picked).

None of the five games shows a preview screen before sending: every one of them builds the full message (header, grid, link) up front and posts it or copies it in the same tap that opens the sheet or the menu.

What does the shared text actually contain?

Every one of the five games' shared text is a small block: a header naming the game and the result, a grid of colored squares standing in for each guess or round, and the link last. The colored-square grid is the format Wordle made common: its own creator added a shareable grid of green, yellow and black squares so a result could be posted without spoiling the answer for anyone still playing, as the New York Times' account of Wordle's creation describes. The five games here each adapt that idea to their own scoring: DailyMetro and DailyFoot use it directly on a guess-by-guess board, while Geopolitix and Le bon rang add a star to a round's row for a side bet won and a separate short row for rounds that are answered with a photo or a map pin rather than a guess. None of the five names the correct answer in the shared text, on the same reasoning as Wordle's own grid: the message has to survive being read by someone who hasn't played yet.

How do you measure whether a share button works?

Three things, none of which needs more than what these games already do. First, an event on the share action itself, split into an "opened" event and a "sent" event, so a share rate can be computed against wins the way the table above does. Second, a UTM tag on the link inside the shared text: Le bon rang's link always carries utm_source=share, which is what let its 100 all-time sessions under that tag get counted as arrivals from a shared link rather than folded into direct traffic. Third, watch the referrer domains a share channel actually produces: t.co, the link shortener behind every X post, sent DailyMetro 1,751 sessions and Le bon rang 671 all-time, and messaging-app referrers (WhatsApp, Messenger, Telegram) sent DailyMetro 1,185 and Le bon rang 576. Both signals undercount the real total, since 30% to 95% of any of these games' sessions arrive with no referrer at all, which is typical for links opened inside a messaging app's in-app browser or reopened from a home-screen bookmark rather than a proof that sharing did nothing.

Put together, a share button is worth watching on three numbers: the rate itself (shares over wins), how much of the destination's traffic a UTM or referrer can actually attribute to it, and whether the code separates "opened" from "sent" so a dismissed sheet doesn't get counted as a share. A creator building their first one can start with just the native-share-and-clipboard fallback above and add the UTM tag before shipping it, which is the one piece that is easy to forget until a month has gone by with no way to answer "did anyone actually send this."