The problem nobody wants to say out loud
If you run events, you already know this routine. You email your speakers a banner and a caption. Some of them post it. Most don't. A few ask for a different size. Someone loses the attachment. Three weeks later your CMO asks whether the speaker programme drove registrations, and the honest answer is that nobody knows.
The tooling hasn't helped much. The category is full of products that will generate a beautiful personalized banner and then count how many people clicked a 'Share' button. That number feels like a result. It isn't one. It tells you how many people opened a share dialog — not how many posted, not how many people saw it, and certainly not how many bought a ticket.
We looked hard at what was available before building anything. One well-known platform tracks conversions with a single URL parameter, and its own public documentation admits the parameter 'can get lost during redirects' — with the suggested fix being to write your own script. Another markets its attribution heavily but publishes no developer documentation at all. A third is refreshingly upfront that a share is recorded when the share dialog opens, not when anything is actually posted.
None of that is dishonest, exactly. It's just the easy 80% of the problem shipped as if it were the whole thing. So we built the other part.
One tap, and the real image — not a link preview
Here's a constraint that shapes everything: no social network lets a web page pre-fill an image into a post. You can share a link, and the network will unfurl whatever preview image that page declares. That's it. Which is why so many 'share your banner' flows end with 'download this image, then upload it to LinkedIn' — a three-step detour that loses most people.
There's a way around it that the category has almost entirely overlooked. Modern browsers can hand a real image file to the operating system's own share sheet. Your speaker taps Share, their phone or laptop opens the native share menu with the finished banner already attached, and they post it straight to Instagram, LinkedIn, WhatsApp — anywhere. No download. No re-upload. No account with us.
This works today in current Chrome, Edge and Safari, on desktop as well as mobile. Firefox doesn't support it, so those users get the image plus a one-click caption copy instead. We checked every competitor we could find and none of them were using this. It's the single biggest difference between a speaker sharing and a speaker meaning to.
The caption carries a short link that belongs to that specific share. Two speakers posting the same banner get two different links. That's what makes the rest possible.
What the loop actually looks like
1. Import your people
Speakers, sponsors and exhibitors from a spreadsheet. Columns are matched to your template fields automatically, and any extra columns you have are kept rather than dropped. Sponsors carry a tier, exhibitors carry a booth number.
2. Send their links
Each person gets a personal, permanent link — sent from your name, with replies coming back to you. No login on their end, ever. The link still works the week before the event, which is when a surprising amount of the sharing actually happens.
3. They share in one tap
They can adjust the fields you allow — their name, their talk title, their photo. Everything else is locked, so your logo and event branding can't be edited away. Then one tap, and the native share sheet does the rest.
4. You see what it produced
Views, shares, clicks and conversions over time. Broken down by channel and country. With a leaderboard of who actually moved the needle, and the revenue attributed to each of them.
Why we count clicks, not shares
We record a share the moment someone taps Share. We want to be precise about what that means: we cannot see whether they completed the post. Nobody can. Once the operating system's share sheet opens, the web page is no longer told what happens — that's a deliberate privacy boundary in the browser, and any tool claiming a verified share count is estimating.
So we treat shares as a ceiling, and clicks as the truth. A click is independently recorded on our side when a real person follows the link, and it can't be inflated by wishful counting.
That only works if 'click' means a human. Every link posted to social media is immediately hit by platform crawlers building previews, by corporate scanners like Microsoft Safe Links and Mimecast checking for malware, and by assorted bots. Left uncounted, they can visibly inflate exactly the number you're relying on. We classify every hit as it arrives and exclude the machines — and we keep the raw records, so if our detection improves we can recalculate historical numbers rather than living with whatever we guessed on the day.
The tracking that doesn't quietly fall apart
This is the part we're most pleased with, and the part that's least visible.
The usual approach to conversion tracking is to put an id in the URL and read it at checkout. It fails constantly, because real checkouts are multi-step, redirect through payment providers, and drop query parameters along the way. The attribution goes missing and nobody notices until the numbers look implausibly low.
Our tracking code captures the id once when the visitor arrives, stores it in the browser, strips it back out of the URL, and then re-attaches it to your own links and forms as the visitor moves through your site. It repairs the trail as it goes. You paste one snippet on your pages and make one call where a purchase completes, with your order id. That's the whole integration.
Removing the id from the visible URL matters for a second reason: Safari shortens the lifetime of tracking data when it spots a tracking parameter sitting in the address bar, and people share the URLs they can see — which would otherwise credit a stranger's purchase to the wrong speaker.
<!-- once, on any page that can lead to a purchase -->
<script>
window.dp = window.dp || function () { (window.dp.q = window.dp.q || []).push(arguments); };
</script>
<script src="https://dynapictures.com/app/widgets/pixel-v1.js" id="dynapictures-pixel" async></script>
<!-- once, where a purchase completes -->
<script>
dp('conversion', { orderId: 'ORDER-123', value: 249, currency: 'EUR' });
</script>What we don't collect
Attribution and surveillance are not the same thing, and the difference is in what gets stored.
- Never a raw IP address. We hash it so repeat visits can be counted, use it briefly to resolve a country, then discard it — the same approach as our countdown timer analytics.
- Attendee names only on a deliberate share. The attendee widget stores a name only when someone actually shares. Opening the dialog, typing, and changing their mind stores nothing at all.
- Hosted in Frankfurt, under GDPR. With a Data Processing Agreement available — relevant, since this whole workflow involves speaker names and photos.
Who this is for
Conference and trade-show organizers with a speaker roster and a sponsor list. Anyone who has ever been asked to justify the marketing spend on an event and had to answer with reach estimates. Teams who want their speakers to promote the event without turning it into three weeks of chasing.
It isn't tied to any event platform, CFP tool or ticketing provider. The widget goes on whatever registration page you have. The tracking works on whatever checkout you run.
Questions we expect
No. They get a link, they open it, they share. There is no signup, no password and no app.