Tracking Confluence article access source from Jira Service Management and other channels

[Raoul]

We have linked a Confluence knowledge base to our Jira Service Management portal. When a user clicks on an article from the portal, they are redirected to the Confluence page with a ?source=search parameter appended to the URL.

We would like to reuse these same articles across multiple channels (e.g., different documentation pages, automated replies, etc.), and we need a way to identify which channel led the user to access a given article.

Specifically:

• Is it possible to define or override the source parameter (e.g., ?source=portal, ?source=email, etc.) when linking to Confluence articles?
• If so, is there any built-in reporting in Confluence or Jira Service Management that allows tracking or filtering article views based on this parameter?

If modifying the source parameter is not supported:

• Are there alternative approaches to track where users are coming from when accessing Confluence articles? (e.g., analytics tools, referrer tracking, or Atlassian-native solutions)

Any best practices or recommended approaches would be greatly appreciated.

[Arkadiusz Wroblewski]

Hello and welcome to the Community @Raoul 

good question.

From what you described, Jira Service Management is already appending ?source=search when the article is opened from the portal. But I do not see that parameter documented anywhere as a supported tracking dimension that you can customize and then report on later inside Atlassian.

What Atlassian does give you natively is a bit different.

Jira Service Management has the knowledge base reports Requests deflected and Requests resolved. Those tell you things like portal article views, whether an article helped deflect a request, and whether a request was resolved with an article link in the comments. That is useful, but it is still knowledge-base performance reporting, not “show me views by source=portal vs source=email vs source=bot”.

https://support.atlassian.com/jira-service-management-cloud/docs/see-how-your-knowledge-base-articles-are-performing/

On the Confluence side, analytics gives you views, plus inbound and outbound link data. But the important limitation there is that Inbound links are about links coming from other Confluence content. That can help if page A in Confluence is driving clicks to page B in Confluence, but it does not solve portal/email/channel attribution.

https://support.atlassian.com/confluence-cloud/docs/view-insights-on-pages/

- if your goal is “how are KB articles doing in the portal?”, use the native JSM reports

- if your goal is “which Confluence pages are sending traffic to other Confluence pages?”, use Confluence inbound link analytics

- if your goal is “I want to know whether this article was opened from the JSM portal, an email, a bot reply, docs, or some other channel”, I would not expect a clean native answer inside Atlassian today. ATM I don't see it gonna happen. 

For that third case, I would usually stop trying to make the source query parameter do more than it really does. The more reliable pattern is to use an external redirect / tracked short link / analytics layer per channel, and send the user to the Confluence article from there. That way you control the attribution yourself instead of hoping Confluence or JSM will expose it later in reporting.