Duplicate pageview removal via normalization segment

Another option, would be to use a segment that looks at the specific date range (and potentially only the platform where the duplication exists), and excluding hits that also have the "Reloads" metric...

Basically, Adobe identifies "reloads" by looking at some of the key dimensions being identical (like page name, url, and a few other fields)....

In the scenario you are describing, the second s.t() call should be treated like a reload... this will mean you will be throwing out real reloads, which if you really want to get creative, you can figure out your average reload rate, and then "add back the average" for the date range.

This would be able to get you a pretty realistic right-sizing.... 

Hi @kayzee ,

Adobe Analytics doesn’t offer a built-in way to directly compare the current page to the previous page across all hits unless you explicitly captured the previous page using getPreviousValue() in your implementation.

Precondition: You have implemented getPreviousValue() and stored the previous page in an eVar or prop (e.g., eVar15 = previousPage).

 

Then your segment can be built like this:

In Segment Builder:

• Container: Hit
• Logic:
• Page exists
• Page does not equal eVar15 (your "previous page" variable)

Limit to Time Period:

Instead of putting "time.period = date" inside the segment, do this:

• When you apply the segment in Workspace, filter the panel to your target date range (e.g., Jan 1–31, 2024).

• Don’t hard-code date into the segment, so it's reusable.

 

Option B: Without Previous Page = Not Feasible for All Pages

If you don’t have a previous page variable captured, Adobe does not let you compare the current and previous hit directly (unlike SQL or CJA).

You might try a Sequential Segment, but it becomes page-specific. Example:

 

Hit 1: Page = “X”
THEN within same visit
Hit 2: Page = “X” → this is duplicate

 

So you could build a Sequential Segment like:

• Step 1: Page equals X
• THEN within 1 hit
• Step 2: Page equals X again

But this would have to be built for every page separately — not scalable.

 

Recommendations: 

 

If you already have a previous page variable (e.g., eVar15):

Use this segment logic:

 

Container: HIT
AND
Page exists
AND
Page does not equal eVar15

 

Screenshot :

 

And apply the time period in the Workspace panel when pulling data

 

If Not Implemented Yet: Quick Fix for Future

Ask your dev team to implement getPreviousValue():

 

s.eVar15 = getPreviousValue(s.pageName, 'gpv_pn');

 

It uses Adobe's append-to-cookie pattern to store the previous value per session.

 

Screenshot of segment:

 

Thanks.

Pradnya

Hi @kayzee ,

It is quite challenging to handle such scenarios directly within Workspace.

Recently, I encountered a similar issue in my application—though in my case, pageviews were being inflated due to a different bug, not just duplicate calls.

Normalising duplicate page view calls can be achieved in Workspace using workarounds and assumptions. However, for this to be reliable, we need to be 100% certain that the duplicate pageviews occurred consistently for all users within a known date range. Only then is it reasonably safe to divide the pageviews for the affected page(s) by 2.

In essence, the approach I used was similar to this SQL-style logic:

ROW_SUM(ADJ_PAGEVIEW_1, ADJ_PAGEVIEW_2)

• ADJ_PAGEVIEW_1: Pageviews divided by 2 to account for the duplication on the specific page(s).

• ADJ_PAGEVIEW_2: Actual pageview count, excluding the affected page(s) during the impacted time period.

By combining segments and calculated metrics creatively, I was able to approximate a more accurate trend.

Example:

I tested the approach by adjusting the pageviews with a factor of 0.5 (i.e., halving them), and it seems to be working as expected in my case.

This workaround helps in analyzing trends and reporting only when the duplicate behavior is uniform and predictable. If the duplication varies—say, some users get 2 duplicate calls while others get 3 or more—then this approach will not yield accurate numbers.

Screenshot:

I discovered the ROW_SUM function from the recently published Calculated Metric Playbook by @mandygeorge .

Thanks,

Nitesh

Hi @kayzee 

Good question, deduplicating pageviews from historical data isn’t always straightforward, but you’re on the right track.

Since Adobe Analytics doesn’t natively support row-level de-duplication like SQL would, your best bet is to create a hit-level segment that filters out consecutive duplicate page views and yes, this can be done without listing each page manually.

Here’s a general approach:

1. Segment Type: Hit-level

2. Logic:

   • Include hits where Page exists

   • AND Page **does not equal Previous Page`

This works because Previous Page is a dimension that lets you compare each hit to the last. So for users who hit the same page multiple times in a row (due to faulty s.t() calls), this will exclude all but the first instance.

To restrict it to the specific time period where the bug occurred, wrap it with:

• Visit Start Date is within your known issue month (or use a custom date range in your workspace)
  
  

One thing to keep in mind that this approach will remove legitimate back-to-back views of the same page as well. So depending on how critical precision is, you may want to isolate this to just the known affected dates and do some validation before using it widely.

Hope this works!