How do I configure pageview meters in Piano Composer?

Key Concepts

Meter Types

Piano Composer supports three meter counting types. All three share the same meter card, naming rules, and configuration options — they differ only in what they count:

• Pageview meter: Increments each time a page is loaded (or each unique page, depending on configuration). This is the most commonly used meter type.

• Session meter: Increments once per session. A session is defined as a period of activity on the site; a new session begins after 30 minutes of inactivity. Use this meter type when you want to limit experiences by visit frequency rather than individual page loads.

• Visit day meter: Increments once per distinct calendar day on which a user visits the site, regardless of how many pages they view or sessions they start that day. Use this meter type when you want to limit experiences based on the number of days a user has visited.

All three meter types can be configured to expire at a given threshold and reset after a defined time period.

Meter Value (Trigger Condition)

A Meter Value condition determines when the experience should trigger relative to the meter, such as:

• At a specific count (for example, Equals 4)

• When the meter increments

• When the meter is expired (depending on how you configure the meter and the condition)

The same trigger conditions apply regardless of whether the meter is counting pageviews, sessions, or visit days.

How Meter Names Work (Shared vs. Independent Counters)

Same Meter Name = Shared Counter Across Experiences

If multiple experiences use the same meter name, they are pointing to the same underlying counter. Any experience that increments that meter will contribute to the same count, regardless of meter type.

This can cause unexpected behavior, including:

• Inflated counts (multiple experiences incrementing the same meter)

• Missed trigger points (an experience expecting to trigger at a specific count may never match because the counter "jumps")

• Templates/actions not displaying as intended because another experience advanced the shared meter first

• Confusing behavior during segmentation changes (it can look like the meter "reset" or "double-counted," but it is usually shared-meter interactions)

• Type conflicts (for example, a session meter and a pageview meter sharing the same name will increment the same counter at different rates, producing unreliable results)

Unique Meter Names = Independent Counters

If you want experiences to behave independently (different counts, different schedules, different audiences), give each experience its own unique meter name.

This is especially important when:

• You run A/B tests

• You have multiple experiences that can appear on the same pages

• You have geo-specific or segment-specific experiences running in parallel

• Different experiences use different meter types (for example, pageviews vs. sessions vs. visit days) — these should always have distinct names

When You Should Share the Same Meter Name

Use the same meter name across experiences only when your goal is to share a single allowance across multiple experiences (for example, multiple paywall variants that should all trigger after the same number of free articles, sessions, or visit days).

Example: If you have several experiences for different article types but want them all to contribute to one "free article" pool, keep the meter name consistent across those experiences.

Unique Pages vs. Every Page Load

This setting applies to pageview meters and changes what counts as a pageview:

• Yes: A given URL counts once; refreshing the same page does not increment the meter.

• No: Each page load (including refreshes) increments the meter.

Session and visit day meters are not affected by this setting, as they count sessions and calendar days respectively — not individual page loads.

Configuring Experiences to Trigger at the Intended Time

Triggering on an Exact Count

If you want an experience to trigger on a specific meter count (for example, the 2nd session, the 4th pageview, or the 3rd visit day), you generally have two options:

1. Expire at the threshold, trigger when it expires

   • Configure the meter to expire after 2 counts (pageviews, sessions, or visit days).

   • Set the Meter Value condition to Expired (or equivalent "expired" logic).

2. Trigger just before the meter expires (recommended for "don't repeat" modals)

   • If you trigger on expiration and the meter remains expired until reset, the experience may re-qualify repeatedly depending on other settings.

A common pattern to show a modal on the 4th count (pageview, session, or visit day) without repeated display:

• Set the meter to expire at 5 counts.

• Configure the experience to show when the meter equals 4.

• Configure the meter to reset after a defined period (for example, 2 weeks).

This "show on N, expire at N+1" approach helps prevent the modal from appearing repeatedly on subsequent counts.

"Increments" vs. "Equals"

If your intent is to trigger an action when the meter advances (rather than matching a value that may remain true across multiple evaluations), consider using an Increments-based condition where available.

This is useful when you want behavior like:

• "Show after the 10th pageview" (on the increment to 10) rather than

• "Show whenever the meter equals 10" (which can re-qualify depending on evaluation timing)

The same logic applies to session and visit day meters: if you want an experience to trigger on the 5th session or 3rd visit day, using "Increments" is more precise than relying on "Equals."

Reset Behavior: Going Offline Does Not Reset the Meter

Taking an experience offline and turning it back on does not reset existing users' meter counts. The meter continues from its prior value unless you explicitly reset it. This applies to pageview, session, and visit day meters equally.

To effectively "reset" metering, you can:

• Change the meter name (starts a brand-new counter).

• Configure the meter to reset after a time period (days/weeks/months).

• Configure the meter reset/expiration rules as part of the meter settings.

Note on reset timing: After a meter resets, it does not immediately restart. The new cycle begins only when the user next visits the site. For monthly resets, the meter resets on the corresponding calendar day of the following month (for example, January 18 resets on February 18). If that day does not exist in the target month, the reset adjusts to the last valid day of that month.

A/B Test Considerations

When A/B testing metered experiences:

• Use distinct meter names per experience/variant if you need clean, independent counting and predictable triggering.

• If multiple A/B test experiences share a meter name, any of them can increment the shared counter, producing unexpected results and making debugging difficult.

• This applies across all meter types — do not share a name between a pageview meter variant and a session meter variant in the same test.

Troubleshooting Checklist

If an experience does not trigger correctly, review the following:

1. Confirm the experience is Live (not offline or test-only in the wrong environment).

2. Check meter name collisions

   • Are multiple experiences using the same meter name unintentionally?

   • Are different meter types (pageviews, sessions, visit days) using the same name?

   • Remember that meter names are case sensitive.

3. Validate "Unique pages only" behavior (pageview meters only)

   • If enabled, make sure your test involves navigating to multiple unique URLs.

   • This setting does not apply to session or visit day meters.

4. Verify the correct meter type is configured

   • Is the meter counting pageviews, sessions, or visit days as intended?

   • A session meter will not increment on every pageview — only once per 30-minute session.

   • A visit day meter will not increment more than once per calendar day, regardless of page load or session count.

5. Review trigger logic

   • Are you triggering on Expired but the meter stays expired (causing repeated eligibility)?

   • Would "show on N, expire at N+1" fit better?

6. Check targeting/exclusions

   • Differences in target-page exclusions between experiences can make behavior look inconsistent even with the same audience.

7. Confirm action/template priority

   • If multiple experiences target the same page, verify Action Exclusivity / prioritization so the intended template is not overridden.

8. Test cleanly

   • Clear cookies / use a fresh browser profile to eliminate prior meter history for all meter types.

Recommended Naming Strategy

Use meter names that communicate the meter type, scope, and purpose. Including the meter type in the name helps prevent accidental sharing between different counter types.

Examples:

• pv_meter_free_articles_global

• session_meter_geo_us_offerA

• visitday_meter_abtest_paywall_variantB

• pv_meter_loggedin_nonsubscriber

• session_meter_upgrade_prompt_variantA

Last updated: June 12, 2026