I have a script that creates Google Calendar events (via the Google Calendar API), inviting/auto-accepting the classroom, teacher and students (all users within our G Suite for Education account). (Yes, it is written in Perl but I don't think that is the problem.) Using this script, I manage 500-600 calendar events per school day.
There is enough rate limiting in the code and quota available in Google API Console that I can create a couple months worth of events in a nightly run. So I usually push one grading period into Google Calendar at a time. (I have over 37,000 events for this 2021-22 school year already pushed to Google Calendar.) This has worked since August 2018.
But, for the past month or so, if I try to create events after mid-January 2022, I get a "Forbidden (403)" after about 50 events are created. However, if I need to change 2021 or early 2022 events (for example, there is an assembly scheduled at school and the class times change, or a class moves from one room to another), I can delete/update/create the usual thousands of events per run with no problem.
As an example, tonight's run deleted and re-created 517 events for January 5, 2022 (there was a schedule change for that day) and made a few other miscellaneous changes, but only created 50 events for January 13, 2022 before a "Forbidden (403)" I'm not going to be able to create anything for a few hours. But, after that (or tomorrow), I'll be able to create 50 more events and then hit the same error again.
Did I miss a change to the API effective with events scheduled in the second week of 2022?
If you are confident that the quotas you use are way below the limits, you might be affected by a bug
There is a already an issue filed on Google's Issue Tracker where several users complain about limit being reach while console shows only 2% of limit being used - so similar to your case.
I recomend you to "star" this issue to increase visibility.
However, beforehand it might worth contacting the Google Workspace support. They can look into your quota usage and see if you are using some "idden quota" you ar enot aware of.
Related
We are using the free level of GA and have been creating reports using Custom Dimensions and Metrics since last summer.
We also use the Google Sheets Analytics add-on to post process data pulled from the API.
Overnight on 16-17 May (UK Time), our reports suddenly started showing as being sampled. Prior to that we had no sampling at all, as our reports are scheduled so I can look back through the revision history to see changes made when the scheduled reports run.
This sampling is occurring in custom reports viewed in the GA platform and in GA sheets. I've done some analysis and it appears to only occur at the point that more than one Custom Dimension is added to a report, or when the GA dimensions ga:hour or ga:dateHour are used (ga:date does not trigger sampling).
All our Custom Dimensions and Custom Metrics are set at Hit level (I've read a post where it was claimed to be due to mixing scopes on Dimensions & Metrics, but we are not doing this).
If I reduce the date range of a query (suggested as a solution on many blogs), the sampling level actually gets worse rather than better.
For the month of May we didn't even hit 4k sessions at property level. I can't find any reference anywhere to any changes being made to GA that would cause sampling to apply to our reports (change documentation, Google Blogs etc).
Is anyone else experiencing this or can anyone shed any light on why this might be happening? Given how we use GA if we can't resolve this then it's a year of work down the drain, so I'm really keen to at least know why this has suddenly happened even if ultimately nothing can be done about it.
Before Tuesday, March 14th, we saw the data lag in Google Analytics at approximately 1-2 hours. (It was never immediate.) You can see this effect on the Conversions > Ecommerce > Overview page if you search by date and select "today" to "today" (1 day's worth of data)
As of Tuesday, March 14th, we started seeing the lag for this overview report anywhere from 8-12 hours, with an inconsistent aggregation time. For example, it is now 4 PM here on the east coast (EDT), and here is a screenshot of our GA overview tab (I have obscured the revenue number for our privacy). As you can see, there are no numbers after 6:00 AM.
We saw this same effect yesterday (about 8-10 hour lag), and the following day the overview report seemed to fix itself (catch up with all of the aggregated data).
Now, what's more interesting, is that if we either A) Add a "Secondary Dimension" or B) use a "Custom Report", we can see all our data near real-time. For example, if I switch into the Ecommerce > Sales Performance report, then add a Secondary Dimension of "Hour of Day", I can see all my data through 2 PM today (about a 2 hour lag as it is now 4:22 pm as I am writing this)
[
Note that to replicate this I sorted the "Hour by day" column by descending order (showing most recent first.)
Our questions are:
(1) Does anyone know why searching by Secondary Dimension or Custom Report shows us the data in more real-time than just looking at the overview report?
(2) Can anyone else confirm that what used to be a 2-3 hour delay now appears as if it is a 8-12 hour delay, starting on or around March 14th (possibly a few days earlier, this is the first day we can remember seeing this effect)
We are using Universal Analytics (with Enhanced E-commerce) implemented via the newer analytics.js. We are NOT using the older ga.js (we moved away from that about a year ago.)
We are not a GA 360 customer, just a regular free account.
From Google Analytics Help Center article.
Processing latency is 24-48 hours. Standard accounts that send more than 200,000 sessions per day to Analytics will result in the reports being refreshed only once a day. This can delay updates to reports and metrics for up to two days. To restore intra-day processing, reduce the number of sessions your account sends to < 200,000 per day. For Analytics 360 accounts, this limit is extended to 2 billion hits per month.
What it means is that for Standard accounts up to 48h delay is normal, if you have more data it can take more if you have less data it can be faster.
Regarding your observation that certain reports load faster than others this is linked to the design of Google Analytics Backends. Google will generate pre-aggregated tables with common reports to speed up consult and that sometimes can takes longer to process. Other non-common reports can't be answered by aggregated reports so it can be responded by a different backend that already has fresher data. So it is considered normal to see different levels of freshness in different reports.
Google Analytics 360 has fresher data of course.
This other table from the HC article highlights some of the differences and has more info.
Today we launched our first campaign on Chartboost. We added 300$ on account and started our first campaign. In less than one our we spent all the money. Then I switched campaign off but still the balance going up in negative. Can you help me why? Beacuse we didn't pay for that additional negative balance we made campaign for 290$ not 450$ ...
What can we do?
The most common reason for campaigns to go over budget is the fact that they reach their budget in the minutes before the first check that compares the spend to the budget. This can happen if you your campaign has a wide target (ie - if you are targeting the whole world for example). Campaigns that have very broad targeting (little to no usage of filtering or available targeting on the dashboard) will serve impressions very quickly and this only increases the probability of exceeding the budget.
It is also very common for CPI campaigns to continue to "Spend Money" even after the campaign has been turned off. The reason why this happens is that we attribute installs to recorded clicks up to 21 days after the click. Also, the Install is not recorded until the 1st bootup of the app. For a number of reasons this 1st bootup may not occur until a couple of days after downloading onto the device from the App Store. There is no way to "turn off installs" for clicks that have already occurred.
Hope this helps.
Background:
I have a Google Analytics account using which I am tracking user activity for web and mobile app. After logging into your account and choosing the web property and the corresponding view, you generally see a dashboard with quick stats like Pageviews, Users, Sessions, Pages/Sessions, Avg. Session Duration, Bounce Rate and percentage of new sessions. You can change the time period (from the top right area of the Dashboard) to get the same stats for that period.
Problem:
Last week, I was interested in the three main stats: Page views, Users and Sessions for a particular day - say, day A. The dashboard showed the following stats:
Pageviews - 1,660,137
Users - 496,068
Sessions - 983,549
This report was based on 100% of sessions.
I go back to the dashboard TODAY and check the same stats for the same day A. Here's what I saw:
Pageviews - 1,660,137
Users - 511,071
Sessions - 1,005,517
This report is also based on 100% of sessions.
Nothing was changed in the tracking code for the web and mobile app. Could someone explain why I have this difference in the stats? Is this normal?
They need some time to update the system, otherwise their system would overwhelm
When you first create a profile it can take up to 48 -72 hours for it to start showing data.
After that time data will appear instantly in the Real-time reports.
Standard reports take longer to finish processing. You need to remember the amount of data that is being processed. Some of the data may appear in the standard reports after a few hours. The numbers have not completed processing for at least 24 hours, so anything you look at then will not be accurate.
When checking Google Analytics never look at todays or yesterdays numbers in the standards reports, if you want accurate information. Things get even more confusing when you consider time zones. When exactly is it yesterday? I have noticed numbers changing as far back as 48 hours. But Google Says in there documentation 24 hours. I am looking for the link in the documentation will post it when I find it.
Found it: Data Limits
Data processing latency
Processing latency is 24-48 hours. Standard accounts that send more
than 200,000 sessions per day to Google Analytics will result in the
reports being refreshed only once a day. This can delay updates to
reports and metrics for up to two days. To restore intra-day
processing, reduce the number of sessions you send to < 200,000 per
day. For Premium accounts, this limit is extended to 2 billion hits
per month.
So try doing the same thing again today but check your last day being Monday. When you check again next week the numbers should be correct.
It means I can't see traffic i got today. Also is it only specific to API or Overall Analytics System?
The reason Google recommends this is because for most of the data, there is about a 24 hour delay before you see it in reports or have it available for pulling with the API. The extra 24 hours on top of that is a buffer for insurance.
So if you look at a report or pull data with the API from like 12 hours ago, and then wait an hour or whatever and pull the data with same ranges/metrics/etc... the numbers won't match up, because by then, more data will have become available. But it's data that was already there (people didn't take a time machine into the past and visit your site, obviously)...it was just not yet processed and available for looking at through the report/API.
A delay in data for reports (or through an API) is not unique to GA. Different reporting tools have different "lags" in data availability, depending on how their databases are setup, how they process the data, how much you are paying for the services, etc... for instance (these are the 4 major tools I've used):
Yahoo Web Analytics data is more or less real-time
Adobe/Omniture SiteCatalyst is..they say real-time but in practice I've seen it take anywhere from instant to an hour
WebTrends has a 24 hour delay
GA has a 24 hour delay
But this isn't as big a deal as you might think. Most companies look at reports by the week, month, quarter, year, so really the delay isn't a problem for the people that matter. The only people that really feel it are the code implementers who have to sit there and wait to see data come in when they are trying to QA an implementation or debug when there is a potential problem.
But even then there are a lot of tools out there that let you see in real-time what is physically being sent to the tool (like firebug, charles proxy, etc...), which greatly helps in QAing. It doesn't really help as far as QAing stuff that requires settings/alterations within the tool's interface, but still, it's a big help.