Occurrences Count in Free Form Table Changes Over Time for the Same Date Range | Community
Skip to main content
Level 2
January 15, 2025
Solved

Occurrences Count in Free Form Table Changes Over Time for the Same Date Range

  • January 15, 2025
  • 5 replies
  • 1220 views

I’m experiencing an issue with the Free Form Table in Adobe Analytics. When I filter for the date range Dec 1, 2024 – Dec 31, 2024 of Event Page, the Occurrences count for this range keeps increasing daily. For example:

  • On Jan 12, 2025, the count shows 1234.
  • On Jan 13, 2025, it increases to 1300.
  • On Jan 15, 2025, it further increases to 1400, and today it shows 1500.

The filter has not changed, and it consistently targets the same date range (Dec 1, 2024 – Dec 31, 2024). Why does this discrepancy happen, and what might be causing the increase in Occurrences over time?

Any explanation or guidance would be appreciated.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Harveer_SinghGi1

Hi @daniel_99 ,

Looking at the number of occurrences that are increasing with time it looks like offline mobile hits only. Adobe libraries can queue the hits with their respective timestamps when a user is offline and send the entire queue alongwith very first hit that goes out after user comes online. Depending upon how long your user's are taking to visit the app again in an online mode you may see hits populating for reporting periods of months back. It is very hard to verify if this using the UI and raw data would be the best option to go about it but couple of options that you can check before that are below,

  • Check if your report suite is event configured to accept offline hits. In report suite settings if the RSID is set to Timestamps not allowed then you can rule out the offline hits tracking possibility
  • Check if your apps are enabled for offline hits tracking. In your app's configuration file (ADBMobileConfig.json file) check the offlineEnabled setting. If it is set as false then you can rule out the offline hits tracking possibility

If both of these settings are configured in favor of offline hits tracking then the data changes that you are seeing could most probably be because of offline hits coming from mobile apps and to verify it you can pull the raw data and as @jennifer_dungan mentioned use cust_hit_time_gmt and hit_time_gmt to confirm it.

Cheers!

 

5 replies

leocwlau
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
January 15, 2025

Normally it should not change unless some data goes into Adobe Analytics and modifying data in Dec-2024. A few possibilities cross my mind:

  1. offline tracking from a mobile app, where mobile app users accessing the app in Dec and without an Internet connection where tracking information cached locally on the device, then accessing the app again with an Internet connection now where locally cached hit sent and reflected in the report.
  2. Usage of Adobe Analytics API (Bulk data insertion, Data repair, Data sources) or feature (Data Source) to modify historical data.
Daniel_99Author
Level 2
January 15, 2025

hi @leocwlau, first of all let me thank you for replying my problem. I checked again and this issue still appears when I filter in November.

bjoern__koth
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
January 15, 2025

Hi @daniel_99 

not sure I can fully follow. Can you maybe add 1-2 screenshots to visualize the issue you are encountering?

Thx!

Cheers from Switzerland!
Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
January 15, 2025

Do you have an segments applied? Particularly "Visitor" based segments....

 

This can be a common occurrence when you are using a visitor based segment because it's looking at all the user's interactions within the panel's timeframe... and as users start to match the criteria, their previous visits and page view and occurrences, etc will start to be included.

 

I know you said you are looking at Dec, and pulling reports in Jan... and I will get to that after this example...

 

For Example.

Let's say you have a segment:

 

VISITOR

      Orders exists

 

Now, let's look at a timeline for that visitor:

 

Visit 1 - Dec 3

  • Page A
  • Page B
  • Page C

Check report on Dec 5th, 0 occurrences

 

Visit 2 - Dec 10

  • Page D
  • Page E

 

Check report on Dec 15th, 0 occurrences

 

 

Visit 3 - Dec 18

  • Page F
  • Order

 

Now this user has made an order, but because the segment is looking at the user in general, the report pulled on Dec 20th will include ALL occurrences from all three visits... so you will get 7.

 

 

Now, to potentially address looking at Jan, and seeing data from Dec change... if you have a segment that has a date range included inside the definition, that overrides the panel date range...

 

So maybe you have a segment like:

 

VISITOR

      Orders exists

      AND

     Last 60 Days

 

 

This would be looking at the Visitor for 60 Days worth of traffic, and not just "Dec" as specified by your panel (so it would include data coming in now in Jan)... as an example...  But in this case, your whole report will reflect the last 60 Days, not just Dec...

 

 

Now, another possibility, as @leocwlau mentioned, could be coming from offline data on a mobile app, or inserted data... 

 

 

I agree with @bjoern__koth, screenshots might help us see something else...  the results you are describing are not typical... 

Daniel_99Author
Level 2
January 16, 2025

thank you guys @bjoern__koth and @jennifer_dungan. Here's some screenshot i got from Dashboard

Jan 13

Jan 14

Jan 16

as you guys can see, the number of occurrences continues to increase day by day even though all the conditions are identical.

Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
January 16, 2025

Is this coming from a mobile app? Since I see iOS and Android... are you absolutely sure you don't have "offline data" enabled?

 

This can result in some users, who use your app with no internet will store a number of tracking calls in the device until the user reconnects to the internet and re-opens the app... all those stored tracking calls are sent in bulk to Adobe... this can result in data coming in after the fact.... 

Daniel_99Author
Level 2
January 16, 2025

@jennifer_dungan, yes this is coming from mobile application. I know your point, however, what I'm wondering is that the same problem occurs when I filter from November 1 to November 30. Why can the number of offline increase simultaneously in both months?

Harveer_SinghGi1
Community Advisor
Harveer_SinghGi1Community AdvisorAccepted solution
Community Advisor
January 16, 2025

Hi @daniel_99 ,

Looking at the number of occurrences that are increasing with time it looks like offline mobile hits only. Adobe libraries can queue the hits with their respective timestamps when a user is offline and send the entire queue alongwith very first hit that goes out after user comes online. Depending upon how long your user's are taking to visit the app again in an online mode you may see hits populating for reporting periods of months back. It is very hard to verify if this using the UI and raw data would be the best option to go about it but couple of options that you can check before that are below,

  • Check if your report suite is event configured to accept offline hits. In report suite settings if the RSID is set to Timestamps not allowed then you can rule out the offline hits tracking possibility
  • Check if your apps are enabled for offline hits tracking. In your app's configuration file (ADBMobileConfig.json file) check the offlineEnabled setting. If it is set as false then you can rule out the offline hits tracking possibility

If both of these settings are configured in favor of offline hits tracking then the data changes that you are seeing could most probably be because of offline hits coming from mobile apps and to verify it you can pull the raw data and as @jennifer_dungan mentioned use cust_hit_time_gmt and hit_time_gmt to confirm it.

Cheers!