Measuring dark social event marketing when the sharing happens in private

Seventeen people from the same manufacturer registered in four days. Nobody in the marketing team ran anything aimed at them. There is one email address on the house list from that company, and the other sixteen have never appeared in your file before.

Dark social event marketing is what happened, and it is the least measured route into a B2B show. Somebody opened the agenda, saw two sessions their team should attend, and pasted the link into a group chat. Every one of those sixteen registrations arrives with an empty source column, and the channel report credits it to direct.

Alexis Madrigal named this in The Atlantic in 2012, writing about traffic that arrives through private sharing and gets logged as direct or typed and bookmarked, and reporting that close to 57 per cent of The Atlantic's social traffic came through that invisible route. The mechanism has not changed since. What has changed is that far more of the sharing now happens inside workplace chat tools, which for a trade show audience is precisely where the decision to attend gets made.

What private sharing looks like in a registration file

The technical reason is specific rather than mysterious. The referrer policy specification published by W3C in 2017 defines a no referrer setting under which no referrer information is sent and the header is omitted entirely. Messaging clients, chat applications and many desktop mail clients either apply that policy or open links in a context that carries nothing.

So the request arrives with no referrer and no campaign parameters. Your analytics has no evidence whatsoever, and absence gets filed as direct, which is the same bucket as somebody typing your url from memory. The distinction between those two situations is the whole problem, and the wider version of it is B8's four way split.

In the registration file, private sharing has a shape. Registrations arrive in bursts. They cluster by employer. They skew towards first time registrants, because the person doing the sharing is usually the one who already knows the show. And they often arrive on mobile within a working day of each other.

Give the share a link of its own

The first instrument is the cheapest. Put a share control on the agenda page, the session pages and the confirmation page, and have it generate a url with its own medium value rather than the page url.

Something like utm_source=peer&utm_medium=peer_share&utm_campaign=tech26-agenda. Now any click from that link carries evidence even when the referrer does not, because the parameters travel inside the url that got pasted.

Two details decide whether it works. The share control has to be more convenient than selecting the address bar, which means a copy button that puts the tagged url on the clipboard in one tap. And the tagged url has to survive your own redirects, which is the hop problem in a different setting and worth testing before launch rather than after.

This instrument undercounts by design. Most sharing still happens through the address bar, and the share button catches the people who noticed it. It gives you a floor.

Per person invite codes and what they buy

The second instrument goes further, because it identifies the sharer.

Give every confirmed registrant a personal invite url containing a code that resolves to their registration id. Put it on the confirmation page and in the confirmation email, framed as a way to bring a colleague. When somebody registers through that url, write the sharer's id onto the new registration row.

Now count. On an edition with 9,600 registrations, suppose 6 per cent of registrants use their invite link at least once, which is 576 people. If those 576 generate a mean of 0.9 registrations each, that is 518 registrations arriving through a named person, of which 310 are addresses that have never been in your file.

That 310 is the interesting number, because it is new audience acquired through people who already chose to attend, at no media cost. It is also the number that justifies putting the invite link somewhere better than the bottom of a confirmation email.

The honest caveat is that some of those 518 would have registered anyway. The invite code tells you the route they took. Whether the invite caused the registration is a different question, and answering it needs a holdout of the kind B6 builds for print.

Counting company domain clusters

The third instrument needs no new code at all, which is why I would start here.

Take one edition's registrations. Strip the domain from each email address and discard the free providers. Group by domain and by a fourteen day window, and flag every domain producing three or more registrations inside one window.

On a file of 9,600 registrations that might return 214 clusters covering 1,150 registrations, with a median cluster size of 4 and a largest of 17. Then intersect that set with the source column: of those 1,150, say 780 arrived with no campaign value at all.

Those 780 are your measurable dark social footprint for the edition, expressed as registrations rather than as a feeling. It is 8.1 per cent of the file, and it is the number to put next to paid social when somebody asks which channels are working.

The cluster count also gives you something operationally useful straight away, which is a list of employers who sent groups. That list belongs with the sales team, because a company that sent four people this year is an exhibitor prospect and a target for a group registration offer next year. Run the same query against the previous edition while you are there, so the list arrives with a note saying which employers are new and which have been sending groups for years.

How much of a burst is really forwarding?

Some of it is not. Large employers produce multiple registrations because they are large, and a company with 4,000 staff in your vertical would send several people whether or not anybody shared a link.

Two adjustments make the number defensible. Set the cluster threshold against the employer's history rather than against zero: a firm that sent five people in each of the last three editions and sends five again is a baseline, and the interesting cases are the ones where the count jumps. And require the registrations to be close together in time, because organic multi person attendance spreads across the campaign while a shared link produces a spike.

Work it through on the 1,150. Suppose 96 of the 214 clusters come from employers that produced a comparable group in the previous edition, and those 96 clusters account for 430 registrations. Removing them leaves 118 clusters and 720 registrations. Apply the timing rule, requiring the registrations in a cluster to arrive inside four working days rather than fourteen, and another 190 fall away, leaving 530.

So the defensible figure is 530 registrations rather than 1,150, which is 5.5 per cent of the edition instead of 12.0 per cent. Both numbers are honest and they answer different questions: 1,150 is how many registrations arrived in employer groups, and 530 is how many arrived in employer groups that look like a response to something shared. Put the second one on the slide and keep the first one in the working file, because somebody will ask how you got there.

What would you do with the number?

Three things, in ascending order of usefulness.

Report it as its own line rather than leaving it inside direct, so the channel mix stops crediting brand strength for peer forwarding.

Then make the sharing easier. If 8 per cent of registrations already arrive this way with no support at all, a group registration path, a shareable session page, and an invite link that says something worth pasting are cheap interventions against a known base.

Then feed the cluster list into exhibitor sales and into the following edition's targeting, because the employers who forwarded a link internally are the ones with a team decision behind their attendance.

Where this stops

None of the three instruments observes the sharing itself, and that is by design rather than by limitation. The message was private, and instrumenting it further would mean tracking people in places where they have a reasonable expectation that nobody is watching. The invite code identifies a sharer who chose to be identified. The cluster count works on data you already hold for the purpose of registering somebody.

The measurement is also a floor rather than an estimate. Share links catch the people who used the button, invite codes catch the people who used the code, and cluster counting catches groups from employers with a shared email domain, which misses consultancies, contractors and anybody using a personal address.

The last limit is causal. A registration arriving through a forwarded link tells you how the person got to the form and nothing about what made them want to come, which was probably a session on the agenda that somebody else found through a channel you did measure. Asking them directly is the only way to see that chain, and self reported attribution in B10 is where that gets designed properly.

Run the cluster query this week, on last edition's file, with a threshold of three registrations from one employer domain inside fourteen days. It takes one group by and a domain exclusion list. The count of registrations sitting in those clusters with an empty source column is your first honest reading of a channel that is currently invisible in your acquisition and attribution reporting.