I have a question regarding "Add Calendar By URL" function in Google Calendar:
How often it is updated (most sources I've found says 24h per day). Does caladress.ics?noCache workaround still works?
How it is updated? If I have a large calendar (e.g 2008 - 2016) and add a single event, does Calendar reupload the whole calendar or check for diff? If check for diff, is there any limitations?
Is there any limit to how long events could be? E.g is it possible to set 5 year event?
1. How often it is updated (most sources I've found says 24h per day).Does caladress.ics?noCache workaround still works?
Based from the Google thread, updates may take a few hours for the new information to be parsed and viewable by your users.
Note: It might take up to 12 hours for changes to show in your Google Calendar.
You can use no-cache to indicate that the returned response cannot be used to satisfy a subsequent request to the same URL without first checking with the server if the response has changed. Here is the documentation and example.
2. How it is updated? If I have a large calendar (e.g 2008 - 2016) and add a single event, does Calendar reupload the whole calendar or check for diff? If check for diff,is there any limitations?
Calendar is updated based on how you will implement the "incremental synchronization" of calendar data. It can be Initial full sync or Incremental sync.
Initial full sync is performed once at the very beginning in order to fully synchronize the client’s state with the server’s state. You can optionally restrict the list request using request parameters if you only want to synchronize a specific subset of resources.
While Incremental sync allows you to retrieve all the resources that have been modified since the last sync request. You need to perform a list request with your most recent sync token specified in the syncToken field. Keep in mind that the result will always contain deleted entries, so that the clients get the chance to remove them from storage.
3. Is there any limit to how long events could be? E.g is it possible to set 5 year event?
For the limitation, the Google Calendar API has a courtesy limit of 1,000,000 queries per day. You can see the calendar usage limits here. It is possible to set an event as long as you haven't reached the limit for the number of events you can create.
Related
My question: how do I update "this and all future" instances in a recurring event which is limited by count so that the total number of events stays consistent?
What is the problem:
Trying to modify recurring event and I follow the below guide:
https://developers.google.com/calendar/recurringevents
Basically to update all future recurring events using a target event, the doc says one need to do two calls:
update existing event to make so it ends before the target event date
create a new recurring event with the same fields except of those need changes.
That works fine until there is an event that is limited by the number of occurrences.
Let's say there is a recurring event limited by 10 occurrences and target event is 5th event.
Now I need to split the original so that the first 4 events goes to the original one (so I update COUNT from 10 to 4) and then I create a new recurring event that holds the rest 6 events (so COUNT is 6 in this case)
My first observation is that this is not how the split events are displayed in google calendar - if I test that manually, the both events still show 10 occurrences but the second one doesn't produce any extra events (I'd expect 14 events from developer perspective, yet there are 10 as any user would expect). That implies there is a different approach here? Is it?
Also if I end up counting manually the number of events, there are still issues with cases like deleting one of the events first (let's say, the 4th event) - now how do I know that I need to show 6 instances in the new one and not 7?
Those thoughts make me think there is a better approach, but I can't find any other alternatives. Any advice on that?
UPDATE
It seems like google does it differently: for example after changing a title for "this and future" events in calendar view, it doesn't seem to produce two different recurring events since if you try to delete "all" events, that will remove all of them completely (rather than deleting only one chunk, either before or after the target event)
It seems like they are creating a bunch of exceptions or maybe "recurring exception" or something to do that. Can't find any examples on how to do that as of now thought.
Can't find any good solution for this after a few days of research and while I need to move forward I ended up with a sort of "compromise" between "good enough UX for my case" and "breaking best practice".
So I ended up updating each event individually which goes against google's warning as shown below but I limited the max count by 50. This is not necessary what others want to do, but this is good enough for the real world use case in my app.
Warning: Do not modify instances individually when you want to modify
the entire recurring event, or "this and following" instances. This
creates lots of exceptions that clutter the calendar, slowing down
access and sending a high number of change notifications to users.
And if user needs to schedule more than that, the user is asked to use "end date" instead.
Again, not ideal by any means so if anyone knows how to handle that correctly or knows how google handles that, you are very welcome to share it! (meh... and I need that for outlook too now...)
UPDATE: just got an idea: as an improvement, one can edit either "all future events" or alternatively the master event + "all previous events" depending on the index of the target event. In this case one can limit the number of requests by 2 (so in case of 50 events I'll need to do 25 requests maximum)
So if user wants to change the title from "Hello" to "Goodby" and if the user picked event number 5 in the series of 50 events to change all future events, we can change the master event to "Goodby" which will change the title of all events, and then update the first 4 events to the original "Hello".
Obligatory summary of comments and chat:
Updating events:
To update specific events in a recurring event you need to update the individual instance by specifying the event instance ID.
This is just the event ID concatenated with a datetime stamp (you can see this when making an Events: instances request for your eventID; if your event ID is xxxxxxxxxxxx then an instance ID would be something like xxxxxxxxxxxx__20200603T170000Z).
Unfortunately there's no direct update-instances endpoint so to update multiple instances in one request you'd need to use batching
The API doesn't have a dedicated method for updating recurring events regardless of the recurrence type, and I presume this is the reason the documentation says to edit the previous recurring event by cutting it down and inserting a new one, as per Google's warning:
Do not modify instances individually when you want to modify the entire recurring event, or "this and following" instances. This creates lots of exceptions that clutter the calendar, slowing down access and sending a high number of change notifications to users.
Batching:
Making a batch update on event instances does keep count consistency. If you edit instances in a batch and then use the 'this and all future events' option when deleting one of the instances of the recurring event they do all get deleted as they're still a part of the recurrance. There is no new event being created in either scenario, the event instances are being changed.
If you play around with Events: instances and use Events: update to change only some instances of an event, then you can see that they all stay part of the same recurrence chain and there is no count change.
For arbitrary large counts, even if you have a recurring event with 9999999 instances, each event still has an ID which you can retrieve from Events: instances. It's stored as a single event for event use, but the IDs of the instances are the identifiers which are different.
Honestly, it's not great that you have to edit each one manually; for large counts like 9999999 it's basically infeasible because you'll have to make a batch request for each set of 100 instances you want to change, but it's the only option available via the API at the moment.
Feature Request:
You can however let Google know that this is a feature that is important for the Calendar API and that you would like to request they implement it. Google's Issue Tracker is a place for developers to report issues and make feature requests for their development services, I'd urge you to make a feature request there, the Calendar API feature request form can be found here.
I am stuck in a case where Google Analytics is recording multiple eCommerce transaction. We have added code on server side to execute GA eCommerce posting code only one time. Still this issue is reproducible for some transaction. The multiple eCommerce transaction are for same transaction Id but on different dates.
On research I found that this case is with small devices (mobile, tablet). The small devices browser caches whole webpage. And when the browser is opened it reload webpage from cache. So each time user opens the browser and page loads from cache hence the causing this issue.
Can anyone help me on this?
Thanks
"Ignore double transaction ids" would be quite a useful setting and we should try and make this a feature request. However at the moment it does not exist.
The only way I can think of would be to use an API script that selects the transaction ids for the last "n" days and then inserts a heap of filters via the management API to exclude hits with that transaction id. After some time (when the caches have presumably expired) you could throw out old filters. This would be only feasible if you have a small number of transactions (I think there is an upper limit to the number of filters a view can have).
Or if your transaction ids are somehow sequential (e.g. if they contain the date) you might be able to construct a regex that matches earlier parts of the sequence (e.g. previous dates) and only let's a transaction pass if it is higher up in the sequence than the last recorded transaction id (or does not let it pass if the date in the transaction id is lower than the current date - remember to update your filter at midnight).
Caveat: I have not actually tried something like this, but it sounds like it should work.
I wish to extract (via the Analytics Core Reporting API) all the transactions made TODAY by users that had a specific ga:eventCategory few weeks ago.
I'm looking to see the date of a transaction and all dated of event that are related to that transaction.
If GA was sql I would join by the ga user and take in the dimension both his transactions date and his dimension update date...
Thanks.
Noam.
Like I have indicated in my comment you can segment the data to include only those users who have the specific event. Segmentation works fine with the core reporting API.
Your segment defintion would look like this:
users::condition::ga:eventCategory==[myEventCategory]
(where obviously the thing in [brackets] is a placeholder that needs to be substituted for the event category name). The "users::" prefix means you are segmenting by user scope (as opposed to sessions), so this will include all sessions in the selected timeframe for users who had the event at least in one of their session (even if the event was outside the selected timeframe).
Select transactionId as dimension and some metric (revenue) and todays date and you are done. Or you would be done if this was actually going to work, but there are at least two caveats:
Google Analytics does not work in realtime, so it's unlikely that TODAYs transactions are fully available (Google says it's 24 hours until the data is processed - actually it might happen faster, but you cannot rely on it).
If a user has deleted his or her cookie she won't be recognized as a recurring user and GA will be unable to segment her out. The longer the interval between the event and the transaction the less likey it is that the GA cookie is still present.
So even with a technically correct query it might be that you won't get the data you need.
I would like to get all events of a recurring event.
Therefore I set the option singleEvents to true.
Now, when I list all events, the response returns endless items (by using nextPageToken). Sure, I can set a MaxTime to have a maximum time limit.
However, I need the syncToken to get only updated events. Otherwise my server has a lot of synchronization tasks. :(
The server gets Push Notifications when something changed. When I create a recurring event, the server recieved the push notification and tries to get the updated events via the last syncToken (using list events).
How can I set a maximum time limit, so I can get the nextSyncToken without having endless nextPages.
My current call:
GET https://www.googleapis.com/calendar/v3/calendars/[CALENDAR]/events?singleEvents=true&syncToken=[SYNC-TOKEN]
When you use a sync token, GCal gives you all the updated events and the only way to limit the amount of events in each response is to use a pager. Set maxResults to limit the amount of results you get per page (max 2500) and then use pageToken until you get another nextSyncToken which means you are at the last page and there are no more events to sync. Each request will either have a nextSyncToken or nextPageToken but no both.
GCal creates 730 events for repeating events without some kind of limit, so 2 years worth of daily events or just under 61 years for a "first Friday of each month" type event. You can check this with the built in API and copying the results to somewhere you can search and count the instances of one of the keys. With defaults, 250 results per page with the 3rd page returning 230.
This isn't just how many are passed with events list and singleEvents true. You'll see in your GCal calendar that the events stop after this time and if you check back tomorrow there won't be another daily event that's been created.
Of course, there could be many long events since the last sync but since you're using push notifications this shouldn't affect you.
Lately I have been dealing with a similar scenario and came up with this solution:
-set singleEvents to false
-for recurring events retrieve instances individually with timeMin and timeMax
Now you can still use syncTokens and the instances() part of the API let's you break up the recurring events into single events with a query. You just have to make sure you do a full sync if you are nearing timeMax again.
Source: https://developers.google.com/google-apps/calendar/v3/reference/events/instances
I'm using Google Analytics API to get the number of page views for each page of my website. In order to reduce the number of api calls, I'm setting an interval for doing this and cache the data on my server. For each api call, I try to get the page views of every page on my site and update them to my database.
Is there a way to get only CHANGED DATA from a specific time stamp? For example, only page views that changed within last 2 hours.
I think it would be a kind of filters (if any) but I could not find it from the documentation here https://developers.google.com/analytics/devguides/reporting/core/v3/reference#filters
You could add a filter for ga:dateHour so that it comes back in the last two hours. But the problem is that it takes Google around 4 hours to process the data. So you wouldn't get anything back for two hours ago.
If you want to see data that is that new you have to use the Realtime api https://developers.google.com/analytics/devguides/reporting/realtime/v3/
What exactly is your query currently? If you do ga:date, ga:dateHour, ga:pagepath, ga:pageviews The results will all be returned in one query (not counting next pages), thats a log way to the 10,000 queries per day limit.
On a side note. What do you mean by changed? Nothing is going to change in data previously processed.