Product Tour pointers not rendering correctly even after Intercom HTML attribution | Community
Skip to main content
Answered

Product Tour pointers not rendering correctly even after Intercom HTML attribution

  • December 13, 2024
  • 3 replies
  • 459 views

I have successfully been able to integrate Product Tour for most of the platform. However,  have a section within my platform where a workflow needs to be completed by the users.

The workflow comprises of 4 steps and it’s a wizard style experience. all the 4 steps have the same URL and just the content on the page changes upon completing a step but the URL remains same.

Issue: The pointers which are meant to appear on the step 2 of the workflow appears on the Step 1 itself. The CSS elements are not visible on the Step 1 but still the pointers appear.

I have tried attributing the HTML with intercom <div> as well, the buttons are even highlighted in Pink within the tour editor after the attribution. It means the attribution worked, Despite this, the pointers appear on Step 1 instead of Step 2.  

Best answer by Sean M

Hi ​@Ankit2709, Seán here from the Intercom engineering support team 🔧

The issue happens because your Product Tour’s CSS selectors aren’t specific enough in a wizard-style workflow where the URL doesn’t change. This causes pointers to appear early, even if the target elements aren’t visible yet. Just to not here selectors like nth-child can match hidden elements and trigger on the wrong step.

To fix this, use unique data-intercom-target attributes for each step explained in more detail here. This ensures Intercom can anchor precisely to the correct element as the page updates.

If you’ve already added these attributes and still see the issue, check that:

  • Each data-intercom-target is unique and appears only on the correct step.

  • The target element is visible only when that step is active.

  • The same data-intercom-target value isn’t reused elsewhere.

For more guidance, see Intercom’s documentation on using CSS selectors for Product Tours.

Let me know if the Intercom div you mentioned was the data-intercom-target attribute or trying the above and its still performing strangely!

3 replies

Forum|alt.badge.img+5
  • Intercom Team
  • Answer
  • November 4, 2025

Hi ​@Ankit2709, Seán here from the Intercom engineering support team 🔧

The issue happens because your Product Tour’s CSS selectors aren’t specific enough in a wizard-style workflow where the URL doesn’t change. This causes pointers to appear early, even if the target elements aren’t visible yet. Just to not here selectors like nth-child can match hidden elements and trigger on the wrong step.

To fix this, use unique data-intercom-target attributes for each step explained in more detail here. This ensures Intercom can anchor precisely to the correct element as the page updates.

If you’ve already added these attributes and still see the issue, check that:

  • Each data-intercom-target is unique and appears only on the correct step.

  • The target element is visible only when that step is active.

  • The same data-intercom-target value isn’t reused elsewhere.

For more guidance, see Intercom’s documentation on using CSS selectors for Product Tours.

Let me know if the Intercom div you mentioned was the data-intercom-target attribute or trying the above and its still performing strangely!


  • New Participant
  • January 17, 2026

It looks like this issue is related to how Intercom injects and styles Product Tour pointers on the page. Even with proper HTML attribution, conflicting CSS, z-index issues, or dynamic DOM changes can prevent pointers from rendering correctly. This often happens on SPAs or pages with heavy custom styling, sso checking element positioning and load timing may help.


  • New Participant
  • January 24, 2026

It looks like a rendering issue that many platforms face when HTML attribution doesn’t load as expected. Similar challenges appear in portals like Shala Darpan, where UI elements depend heavily on proper script execution. A small config or cache fix often solves it.