Hotjar and Microsoft Clarity under the PDPL: what to watch for?

What are Hotjar and Microsoft Clarity in the PDPL context?

Hotjar and Microsoft Clarity are session replay/heatmap tools that let you see how users scroll, click, move the mouse, and interact on a website/app. Under personal data protection rules, the issue is not the tool’s name but the fact that it can record input content, device identifiers, browsing behavior, and other data that may relate to an individual.

With the PDPL, when you use this type of tracker, your business needs to determine: what data is collected, whether identity can be inferred, whether data is transferred abroad, who the data processors are, and whether users have been properly informed and have given consent.

What risks do Hotjar/Clarity session replay pose under the PDPL?

The biggest risk is that session replay may “capture” personal data unintentionally, such as emails, phone numbers, addresses, order codes, session tokens, or form contents if masking is misconfigured. This increases the risk of violating data minimization principles and data protection obligations under the regulations.

Some real-world scenarios in Vietnamese SMEs:

• A signup form has a phone number field but no masking; the replay records each character clearly.
• The checkout page displays name, phone number, and shipping address in the session replay.
• An internal/CRM page has tracking scripts, allowing staff to see customer data in replay videos.
• A heatmap + device ID + access time is sufficient to infer a specific person in a narrow context.

If you use Hotjar/Clarity for landing pages, e-commerce, SaaS, fintech, health, or education, treat this as an activity that requires tighter controls than ordinary analytics.

Do you need consent to use Hotjar/Clarity?

Yes, in most cases you should obtain explicit consent before activating session replay/heatmaps, especially when the tool may capture personal data or sensitive data. This is the safest way to meet transparency requirements and reduce future disputes.

Do not lump this tracker into “strictly necessary” cookies if it is not truly essential for core functionality. If you only want to measure UX/marketing effectiveness, let users opt out and only activate after they consent.

When should it be treated as requiring consent?

• The tool records screens/sessions.
• It can capture input fields, even inadvertently.
• Data is used for behavioral analytics, marketing, or conversion optimization.
• Data is transferred to an overseas provider or third party.

What should you do on the cookie banner?

• State the purposes: session replay, heatmaps, experience optimization.
• Allow accept/decline by category.
• Do not pre-enable before the user chooses if the tracker is not necessary.
• Store evidence of consent to demonstrate during inspections.

How to reduce risk when using session replay?

Design by the principle “see nothing you don’t need to see.” Replays should only serve UX optimization and must not turn into a trove of user data.

Practical measures:

• Mask all input fields by default; only unmask when truly needed and under control.
• Exclude URLs with sensitive data: /checkout, /payment, /account, /profile, /admin.
• Hide text inside iframes, modals, or components with order data.
• Disable recording on pages with OTPs, passwords, medical records, or HR records.
• Limit internal access by role.
• Log who views replays for internal audits.

If you are a developer, check each tool’s event binding, DOM capture, and auto-redaction settings before release. Do not rely solely on the provider’s “secure by default” settings.

What if PII was captured by mistake?

When you discover that session replays have captured PII unexpectedly, immediately contain the issue, stop the configuration causing the leak, assess the impact, and keep evidence of your handling. If the incident meets the threshold of a “personal data breach,” you must notify within 72 hours of discovery per the regulations.

For serious incidents, have a predefined internal process: who detects, who decides to pause the tracker, who assesses the impact, who informs legal counsel and the competent authority when needed.

What should Vietnamese businesses prepare before enabling Hotjar/Clarity?

Before activating the tracker, SMEs should do five minimum tasks: define the purpose; verify collected data; enable masking/redaction; adjust the consent banner; and keep processing records. This is far more effective in reducing risk than simply stating “we comply with the PDPL.”

If you are using multiple trackers at once, create a checklist for each tool: purpose, data, data recipients, retention, opt-out mechanism, and masking measures. When there is an inspection or dispute, this documentation is very useful.

You can use consent.vn to deploy cookie banners, store consent evidence, and manage DSARs in a way that’s streamlined for product and marketing teams.

Source: the Personal Data Protection Law (Law 91/2025/QH15) on thuvienphapluat.vn; Decree 13/2023/ND-CP on thuvienphapluat.vn; A05/Ministry of Public Security on bocongan.gov.vn