You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/form-submissions-tracking.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ If you use the form submissions tracking feature, then these count towards your
11
11
12
12
Plausible can automatically detect and track when visitors submit forms on your website. This feature helps you measure engagement with contact forms, signup forms, and other key conversion points without adding custom code.
13
13
14
-
When Form submissions tracking is enabled, Plausible automatically detects all forms across your site and records submissions as a single goal. This means you don’t need to configure individual goals for each form — Plausible handles it for you.
14
+
When Form submissions tracking is enabled, Plausible automatically detects all forms across your site and records submissions as a single goal. This means you don’t need to configure individual goals for each form: Plausible handles it for you.
15
15
16
16
All detected form submissions are grouped under one goal, and you can analyze where conversions happen by filtering results by page path or referrer. For example, if the same form appears on multiple pages, Plausible will show how many submissions occurred on each specific page.
Copy file name to clipboardExpand all lines: docs/google-analytics-import.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,7 @@ description: "Import your historical Google Analytics 4 data into Plausible Anal
23
23
"name": "Why are the numbers higher in Plausible than in Google Analytics?",
24
24
"acceptedAnswer": {
25
25
"@type": "Answer",
26
-
"text": "Plausible does not require cookie consent and is not blocked by most browser-level tracking protection. GA4 is blocked by Safari ITP, Firefox Enhanced Tracking Protection and many ad blockers. Plausible natively captures more traffic, particularly from privacy-conscious users."
26
+
"text": "Plausible does not require cookie consent and is blocked far less often than Google Analytics by browser-level tracking protection. GA4 is blocked by Safari ITP, Firefox Enhanced Tracking Protection and many ad blockers. Plausible natively captures more traffic, particularly from privacy-conscious users."
27
27
}
28
28
},
29
29
{
@@ -208,7 +208,7 @@ GA4 uses modeled data and consent mode to estimate traffic for users who decline
208
208
209
209
**Numbers are higher in Plausible than in GA4**
210
210
211
-
Plausible does not require cookie consent and is not blocked by most browser-level tracking protection. GA4 is blocked by Safari ITP, Firefox Enhanced Tracking Protection and many ad blockers. Plausible natively captures more traffic, particularly from privacy-conscious users.
211
+
Plausible does not require cookie consent and is blocked far less often than Google Analytics by browser-level tracking protection. GA4 is blocked by Safari ITP, Firefox Enhanced Tracking Protection and many ad blockers. Plausible natively captures more traffic, particularly from privacy-conscious users.
212
212
213
213
**Import appears to complete but data is missing**
After entering the email, they are redirected to identity provider's portal. The provider validates their identity if they haven't logged in there yet or uses an already validated identity from an existing session. The identity information (email, name) is then securely sent back to Plausible. At that point, their account is automatically created in Plausible—no manual setup needed.
29
+
After entering the email, they are redirected to identity provider's portal. The provider validates their identity if they haven't logged in there yet or uses an already validated identity from an existing session. The identity information (email, name) is then securely sent back to Plausible. At that point, their account is automatically created in Plausible. No manual setup needed.
30
30
31
31
### Provisioning
32
32
33
33
When someone logs in through SSO, we will first check if there's an existing team member with a matching email address and SSO configuration. If a match is found, they're logged in as that user. If not, a new user would be created automatically and added to the team whose configured SSO domain matches the email’s domain.
34
34
35
35
By default, new members are assigned the Viewer role, but you can change it as needed.
36
36
37
-
A user signing in through SSO can only belong to one team. Team assignment is based on the domain in their email address. Each SSO domain must be unique—a single domain can't be linked to more than one team at once.
37
+
A user signing in through SSO can only belong to one team. Team assignment is based on the domain in their email address. Each SSO domain must be unique: a single domain can't be linked to more than one team at once.
38
38
39
39
You can read more about domains at [SSO Domains](#sso-domains).
40
40
41
41
### Security
42
42
43
-
When you configure SSO for your team for the first time, existing members can still log in using their email and password. However, once a member signs in via your identity provider, their account becomes SSO-only—they can no longer use standard login credentials.
43
+
When you configure SSO for your team for the first time, existing members can still log in using their email and password. However, once a member signs in via your identity provider, their account becomes SSO-only: they can no longer use standard login credentials.
44
44
45
45
Standard and SSO users can coexist on the same team as long as the "Force Single Sign-On" option is disabled.
46
46
@@ -176,7 +176,7 @@ Providing this fallback is important to provide a way to resolve issues with mis
176
176
177
177
## SSO Domains
178
178
179
-
Before it's possible to log in through SSO, you need to add at least one domain and verify its ownership using one of the three available methods. SSO will not work—even if SAML is fully configured—until a domain is added and verified.
179
+
Before it's possible to log in through SSO, you need to add at least one domain and verify its ownership using one of the three available methods. SSO will not workuntil a domain is added and verified, even if SAML is fully configured.
180
180
181
181
When someone tries to log in via SSO, Plausible checks the domain part of their email address (the part after the “@”) against your configured domains. If a match is found, the user is redirected to the appropriate identity provider for authentication.
182
182
@@ -223,7 +223,7 @@ Following settings are available:
223
223
-**Session timeout (minutes)**: Session timeout for users logged in through SSO. Maximum is 12 hours. Default is 360 minutes (6 hours).
224
224
225
225
:::tip Session timeouts in Plausible and in identity provider are different things
226
-
SSO account session timeout in Plausible is always counted relative to the time of last login, not user activity. Unlike standard accounts, simply staying active won’t extend the session. However, this doesn’t mean users need to manually log in again when the session expires. When the timeout is reached, Plausible automatically redirects to your identity provider. If the user's session is still valid there, they’re seamlessly returned to Plausible—right back to the last page they visited. Plausible's session timeout is typically shorter than the one configured at your identity provider. This helps keep user access in sync. For example, if a user's identity is removed at the provider level, their Plausible session will expire shortly after, limiting unauthorized access.
226
+
SSO account session timeout in Plausible is always counted relative to the time of last login, not user activity. Unlike standard accounts, simply staying active won’t extend the session. However, this doesn’t mean users need to manually log in again when the session expires. When the timeout is reached, Plausible automatically redirects to your identity provider. If the user's session is still valid there, they’re seamlessly returned to Plausible, right back to the last page they visited. Plausible's session timeout is typically shorter than the one configured at your identity provider. This helps keep user access in sync. For example, if a user's identity is removed at the provider level, their Plausible session will expire shortly after, limiting unauthorized access.
0 commit comments