GUIDE

Combining a Custom OG Image With a Tracked Sharing Link

A great OG image and a trackable link are usually built with two different tools and glued together by hand. Here's what it looks like when they're the same object — and why that changes what you can actually measure.

August 16, 20266 min read

Most teams treat the preview image and the tracking link as two separate problems, solved by two separate tools, at two separate points in the process. Someone designs or generates an OG image and drops it into the site's meta tags. Separately, someone else runs the URL through a link shortener to get click data. The two never talk to each other — the image lives at the page level, the tracking lives at the link level, and neither system knows the other exists. That gap is small until you actually want to answer a specific question: did the image affect whether people clicked?

Why the split setup breaks down

With OG image and click tracking handled by separate tools, you can see total clicks on a shortened link, and you can see what image is attached to the page it points to. What you can't easily do is connect the two — if you want to try two different images and see which one drove more clicks, you'd need to swap the og:image tag on the live page, wait for enough traffic, swap it again, and somehow keep the click counts for each period straight. That's fragile: traffic isn't evenly distributed across time, so the two periods aren't a fair comparison, and platform caching means a chunk of your audience will still see the old image for a while after you switch it regardless of what the tag now says.

What changes when the image is part of the link

When the OG image and the tracked link are the same system, the image becomes an attribute of the link rather than a fixed property of the destination page. That reframing matters more than it sounds like it should. It means a single link can serve different images to different segments of its traffic simultaneously — not sequentially, not one-week-at-a-time — and the click data comes back already split by which image the person actually saw. It also means you can generate a purpose-built image for a specific link — a version with campaign-specific copy or a seasonal treatment — without touching the underlying page's default og:image at all, so the rest of the site's previews stay untouched.

The workflow, concretely

In practice this looks like: generate an OG image from a template, with whatever text, color, or asset variables are specific to this share. Attach that image to a sharing link on your own branded domain rather than the page's default meta tags. Distribute that link — in a newsletter, a social post, a QR code, wherever. Every click on that link is now attributed both to the destination and to that specific image, with device, country, and referrer data captured the same way it would be for any tracked link. If you want to compare two images for the same destination, you attach two variants to the same link and let clicks split across them automatically, rather than manually alternating which image is live and hoping the traffic during each period is comparable.

Why this matters most for one-off shares

This combination is most valuable specifically for content that doesn't have a permanent, evergreen page-level OG image worth optimizing in isolation — a single announcement, a limited-time offer, a specific social campaign. For a permanent blog post or product page, it usually makes sense to settle on one strong og:image and leave it. But a one-off share doesn't get that luxury; it gets one shot, often in a single channel, and there's no point iterating on the page's meta tags for something that's only going to be shared once. Attaching a purpose-built image directly to the link, with its own tracking, lets you treat that one-off share with the same rigor as a page you'd optimize over months, compressed into a single send.

What you actually learn from this that you wouldn't otherwise

  • Whether the image itself is driving clicks, independent of the copy around it or the channel it's shared in — because the image is the only variable changing.
  • Which image performs best for which channel — a bold, high-contrast image might win in a busy Slack community while a cleaner, more editorial one wins in a newsletter, and you'd never see that difference from page-level swapping.
  • Real click data per variant with device and referrer context, rather than a rough before/after comparison across two different time windows with different traffic conditions.

This also protects the rest of your site's previews

There's a second, quieter benefit to keeping the campaign-specific image separate from the page's default og:image: it means an aggressive, attention-grabbing image built for one specific channel doesn't end up as the permanent preview for that page everywhere else it's shared. A bold, high-contrast image with campaign-specific text might be exactly right for a single paid push into a particular audience, and completely wrong as the evergreen preview someone sees when they organically share the page six months later. When the campaign image lives on the link rather than overwriting the page's meta tags, the page's default preview stays untouched, and the campaign-specific version only shows up through the specific link it was built for.

How this differs from just changing the og:image tag temporarily

It's worth being explicit about why this isn't equivalent to just editing the page's og:image field for a week and then editing it back. Beyond the traffic-comparison and caching problems already covered, there's a coordination cost: someone has to remember to make the change, remember to revert it, and hope nothing else on the page changes in between that gets attributed to the wrong period. A link-level image sidesteps all of that, because there's nothing to remember to revert — the campaign image only ever applied to the specific link it was attached to, and the page's own meta tags were never touched in the first place.

How this works in useopengraph

This is the combination useopengraph's OG image generation and sharing links are built around: generate an image from a template with the variables specific to what you're sharing, attach it directly to a branded, trackable sharing link, and get click analytics by day, country, device, and referrer for that link specifically. On the Growth plan and above, you can attach more than one image variant to the same link and get a statistical significance read on which one is actually winning, rather than eyeballing a small gap in raw click counts. The image and the link stop being two separate tools glued together after the fact, and become one object you can iterate on together.

The preview image is often the first thing anyone sees before deciding whether to click at all. Measuring it separately from the click data it's supposed to be influencing has always been a workaround. Combining them isn't a bigger feature set — it's closing a gap that shouldn't have existed in the first place.

A note on keeping the pairing organized

As this pattern scales beyond one or two campaigns, it's worth naming links descriptively rather than letting the destination URL alone stand in for what a link is. A link created for a specific launch, with a specific image, sitting alongside a dozen other links pointing at the same page for different campaigns, is hard to tell apart later if the only distinguishing information is the destination. A short, consistent naming convention — the channel, the campaign, and roughly when it went out — makes it possible to come back to click data weeks later and know immediately which image and which context produced which numbers, rather than having to reconstruct that from memory or from digging through old messages to figure out what a given link was even for.

Stop paying per seat
for a usage-shaped problem.

Unlimited teammates, one usage pool. Start free with the scanner — no card required.