Sharing and Collaboration

A weekly project has been running for about a year. Four people open it every Monday, the numbers in it get quoted in a meeting, and over time it has become the thing everybody means when they say "the weekly numbers". Nobody thinks of it as infrastructure, but that is what it has become.

Then somebody new joins, asks for access, and is given it in the ordinary way, by opening the share dialog and typing their name. A fortnight later the Monday meeting starts with two people disagreeing about a figure, and it turns out that the new joiner had been exploring, had changed a segment on the second panel to something more relevant to their own team, and had saved. The project everybody depends on is now a slightly different project, and no version of it exists anywhere that says what it used to be.

Nothing malicious happened, and nobody did anything the interface told them not to. The share dialog offered a choice, the choice was made in about two seconds by somebody who wanted to be helpful, and the difference between the option chosen and the one beside it was the difference between a reader and a co-owner.

Which is why this section spends most of its length on three options in one dropdown.

Three roles, and what each one really hands over

When you share a project with somebody inside your organization, you choose the role they get, and the three are genuinely different in kind rather than in degree.

Edit original makes them a co-owner of the original. They can change it, save over it, and in most respects manage it the way you can. That is the correct choice for an analyst you are genuinely working with, and the wrong one for almost everybody else, because it is also the choice that lets a well-meaning person permanently alter a report four other teams read.

Edit copy lets them do everything except save over your version. They open it, work in it, break things, rearrange it, and when they want to keep what they have done they save their own copy. For a colleague who understands the data and wants to take your analysis somewhere of their own, this is almost always the right answer, and it is the option most people should be choosing when they reflexively choose the first one. Adobe agrees, incidentally: the share dialog states that projects are shared as Edit copy by default, so the safer answer is already the one sitting there until somebody changes it.

Read only gives them the project as a reader. They cannot save, and they do not get the left rail, which means they cannot drag new components in and build something that was never intended. They can still read, filter within what is there, and take the numbers away. For a stakeholder who wants the answer rather than the tool, this is both safer and kinder, because a person who does not build reports is not helped by being handed a component library.

One detail is worth holding on to, because it makes permissions behave in a way people do not expect. Where a person ends up with more than one role, through a group as well as directly for instance, they get the most permissive of them. So adding somebody as a viewer does not take away edit rights they already had through a team, and a project that appears carefully locked down can be wide open to half its audience for reasons that are not visible in the share dialog.

Sharing with people who do not have Adobe Analytics

Some of the people who need the answer do not have a login, and were never going to get one. Adobe handles this with links rather than accounts.

A project can be shared as a read-only link to somebody inside the organization who has no Analytics access, and it can be published as a public link for people outside it entirely. Both give a view of the project without a login, both can be disabled or regenerated at any time, and the public one has a throughput limit measured in the region of a couple of hundred people every few minutes, which matters only if a link ends up somewhere it was not meant to go.

That last clause deserves more attention than it usually gets. A public link is a URL that shows your data to anybody holding it, and URLs travel: pasted into a chat, forwarded, included in a deck that gets emailed onward. Before creating one it is worth asking what is actually visible through it, which is exactly what curation controls, and worth deciding who owns the job of turning it off when the campaign it was made for is over.

Scheduling, and why an emailed report gets read

The other half of sharing is the version nobody has to open anything to receive. A project can be scheduled to send itself, as a file, to a list of people, on a rhythm you choose.

It is worth being clear-eyed about why this matters, because it is not convenience. A project that has to be opened competes with everything else somebody could do with those two minutes, and loses most weeks. A file that arrives on Monday morning in front of somebody who was going to read their email anyway does not have to win that competition. The same numbers, delivered rather than published, get looked at several times more often, and the difference is entirely about whose effort it costs.

Two things go wrong with scheduled projects and both are quiet. The first is that a schedule outlives its reason: the campaign ends, the team reorganizes, and the report keeps arriving for another year, read by nobody and trusted by everybody who sees the subject line. The second is the interaction with dynamic rows described in Freeform Tables, where a table showing the top ten of something silently shows a different ten each month, which is precisely the wrong behavior in a report whose entire purpose is comparison over time.

Three fields, and a two-second decision

⤢

Three fields, and the one you type into decides whether the person becomes a co-owner or a reader. Note the line under the link: projects are shared as Edit copy by default, which means the safer option is already selected until somebody changes it.

Follow along: hand the same project over three different ways

The roles are easier to hold on to once you have seen what each one actually produces, and the fastest way to see that is to look at your own project through somebody else's eyes.

There is more to sharing than this, and this is the part that decides whether it goes wrong. Step 4 is the one that changes behavior, because seeing a project without the left rail is what makes the difference between the roles concrete rather than theoretical.

The whole of the handover problem

Sharing a project means choosing between Edit original, which makes a co-owner who can save over your work, Edit copy, which lets somebody do anything except that, and Read only, which gives a reader the answers without the toolbox. The middle option is right far more often than it gets chosen, and it is already the default, the most permissive role wins wherever somebody holds more than one, and two people editing the same project at once will overwrite each other with no warning of any kind. Links extend all of this to people without Adobe logins, and a public link is a URL that should be assumed to travel. Scheduling is the version that actually gets read, and it needs an end date and pinned rows or it becomes a zombie report comparing different things every month.

Set alongside curation, that is the whole of the handover problem: curate so a reader cannot pick the wrong metric, annotate so nobody investigates the same dip twice, and share at the level that matches what the person is really being asked to do.

There is one thing left that decides whether any of this works at all, and it has nothing to do with permissions. A project that four teams depend on, holding twenty tables across eight panels with a year of data behind it, has to actually open in front of somebody who is presenting in ninety seconds. Workspace Performance and Limits covers what makes a project slow, what the real ceilings are, and why the project everybody relies on is usually the one that takes longest to load.