I would like to retrieve historical travel times from HERE API.
Following the API documentation for 'Calculate Route', I requested travel times for a fixed route at a fixed departure time for different days in the past, using mode=fastest;car;traffic:enabled.
The result is the same route every day and a weekday pattern (i.e., same travel time each Monday) for travel times. This obviously does not include actual traffic conditions on the specified day.
From the documentation, I would have expected to get specific travel times for each day in the past (up to one year).
Did I miss something or is this just not possible?
Thanks a lot for any help!
It is not possible to get the exact route for a past date. For any date other than NOW(current time), the route is calculated with the accumulated historical data taking into consideration the week day, time of the day, any construction work etc.
Related
I was trying the HERE routing maps to find out if it actually give me reasonable time for the distances that I already know.
Source : 12.971076,77.537375
Destination: 12.975366,77.606841
https://route.ls.hereapi.com/routing/7.2/calculateroute.json?waypoint0=12.971076,77.537375&waypoint1=12.975366,77.606841&mode=fastest%3Bcar%3Btraffic%3Aenabled&departure=now&apiKey={API-Key}
I see that the API always gives me the time taken in between 33/34 minutes on all days of the week and all hours of the day.
Any idea on how the travel time is calculated?
In my opinion, for the above coordinates, during the rush hours it takes anywhere between 50-80 minutes.
We have replicated the same API, and got 2 different travel time by altering the value of departure. Can you please try to use below DEPARTURE time format.
https://route.ls.hereapi.com/routing/7.2/calculateroute.json?waypoint0=12.971076,77.537375&waypoint1=12.975366,77.606841&mode=fastest%3Bcar%3Btraffic%3Aenabled&departure=2020-03-19T13:00:00&apiKey=xxxxxx
https://route.ls.hereapi.com/routing/7.2/calculateroute.json?waypoint0=12.971076,77.537375&waypoint1=12.975366,77.606841&mode=fastest%3Bcar%3Btraffic%3Aenabled&departure=2020-03-19T10:00:00&apiKey=xxxxxx
I'm doing this request in Python / Postman:
https://www.googleapis.com/analytics/v3/data/mcf?
ids=ga:xxxx&metrics=
mcf:assistedConversions&
dimensions=&
start-date=2011-10-01&
end-date=2011-10-31
But I only seem to be able to get the total number of results.
1/ Can I get it on a daily granularity? I know that GA API has the ga:date optional parameter, but this does not work in combination with the MCF API and I couldn't find anything similar for MCF.
Do I have to iterate through each day to get the results at a daily granularity?
2/ Is the 30 days lookback applied to API calls? If just put the end date 4 years ahead, will it give me the full results?
Daily granularity: You should add the mcf:nthDay dimension to break the results down into individual days within the specified range:
Index for each day in the specified date range. Index for the first
day (i.e., start-date) in the date range is 0, 1 for the second day,
and so on.
Loopback time: yes it's 30 days and can'be be changed:
Note: The Multi-Channel Funnels Reporting API uses a non-adjustable
30-day lookback window.
If just put the end date 4 years ahead, will it give me the full results?
Why don't you test to find out and let us know :) ?
In the REAL-TIME / Overview page, you can see how much people are currently browsing your site. Although, how do you know if this current value is good or bad? I would like to know how much people were browsing my site the same time the day before, so I would know if I have 5% more or less people.
Also, how would I know if the site is doing it better or worse than 1, 2 or 5 hours before? The REAL-TIME shows the last 30 minutes of per minute page-views, but how do I know if the site is going down or up compared to a few hours before? 30 minutes is not enough.
Is there any add-on to add, custom modification to make, or free/paid service to complement?
You want to use the standard ("core") reporting. The dimensions that will help you are (UI / API):
Hour / ga:hour: A two-digit hour of the day ranging from 00-23 in the timezone configured for the account. This value is also corrected for daylight savings time. If the timezone follows daylight savings time, there will be an apparent bump in the number of sessions during the changeover hour (e.g., between 1:00 and 2:00) for the day per year when that hour repeats. A corresponding hour with zero sessions will occur at the opposite changeover. (Google Analytics does not track user time more precisely than hours.)
Hour of day / ga:dateHour: Combined values of ga:date and ga:hour formated as YYYYMMDDHH
Date Hour and Minute / ga:dateHourMinute: Combined values of ga:date, ga:hour and ga:minute formated as YYYYMMDDHHMM
Hour Index / ga:nthHour: The index for each hour in the specified date range. The index for the first hour of the first day (i.e., start-date) in the date range is 0, for the next hour 1, and so on
With the UI you can add a secondary dimension to reports or build custom reports, with the API you can need to build your requests from scratch (try the explorer, official API doc).
I imagined there would be more literature on this, but I'm having trouble finding any. I have a lot of non-algebraically-aggregatable time series data (that is to say, points for which no function exists that I could use to aggregate them to a higher granularity-- stuff like unique active users, unique contributors, etc... where knowing the amount I had every minute of some hour does not tell me how many I had total during the hour). Currently, I'm just storing and presenting all of this data in UTC. The problem is that many of my clients find this confusing-- understandably so. Because the data is non-algebraically-aggregatable, there's no way to get from UTC data for 1 day midnight- midnight to, say, PST data from midnight to midnight. Recalculation would need to be done from raw data.
So:
Recalculation from raw data is prohibitively expensive for some complicated analytics graphs
We could store all data for all time zones, but this would increase the amount of data we store x24.
All of that said, how do other people deal with this issue? Here's how Google Analytics does it, but this seems insufficient for my use case because I know if I open the multiple timezone can of worms, clients will ask for more than one. This will also take a lot of work that doesn't seem worth the effort as just adding timezone support won't be extremely noticeable or a huge win. What I'm really hoping for is some clever design solution that just presents the UTC data in some intuitive enough way that it's no longer confusing for people in other timezones. Has anyone dealt with similar problems and come upon a solution I'm missing?
First of all, you should recognize that there a lot more than 24 time zones. In order to accurately take into account how people actually use time worldwide, you should be using IANA time zones, of which there are over 500. See also Wikipedia and the timezone tag wiki.
If you are dealing with individual points (discreet timestamps), then you can certainly convert from UTC to any time zone you wish, on the fly as you render your graph. You just need to also keep in mind that the range of data you query will also need to be translated to that time zone.
But if you are talking about aggregating data by the "day" of a specific time zone, then there is no magic bullet. You will need to decide ahead of time which time zones you want to support and calculate each one separately. When you do this, recognize that it's not just the view that's changing. Since the day boundaries are different for each time zone, then the data for each time zone could potentially have very different daily totals.
You should also be aware that not every day has 24 hours. If the day happens to be the date of a daylight saving time transition, it could have 23, 23.5, 24.5, or 25 hours. This could potentially affect how you draw your graph.
One approach you might consider is to be time zone ignorant in your aggregations, rather than using UTC or any specific time zone. Of course this depends heavily on the context of your data, but it is appropriate in certain circumstances. For example, on an invoice, you might care less about the specific timestamps, and more about which calendar date the invoice was assigned to. In that case, once a date is assigned, you would just aggregate on that date. Even if the company operates over multiple time zones, you wouldn't care about that in aggregate.
As far as some clever design that abstracts this from the user, I'm afraid I haven't seen much. The only two choices you really have are timezone-adjusted aggregations (UTC or otherwise), and time zone ignorant aggregations for calendar-date contexts.
We had similar issues to roll up the data for Generation in renewable. We went with three options User / Farm / UTC.
If user selects USER then all the data would be based on his browser Time zone. And Yesterday meant 24 hours till last mid night in user local time.
Similarly if it was Farm, then we take the Farm local and derive the same.
UTC is standard similar to what you have implemented.
GA Unique Visitors data isn't making sense to me. From the GA FAQ we get the following definition for 'Visits vs. Visitors'
"The initial session by a user during any given date range is considered to be an additional visit and an additional visitor. Any future sessions from the same user during the selected time period are counted as additional visits, but not as additional visitors. "
The part that I can't resolve with the GA graph is "Any future sessions from the same user during the selected time period are counted as additional visits, but not as additional visitors". For the graph below covering a 30-day period, I would understand the GA definition to mean that the data represents uniqueness across all 30 days, right? But if you look at the screen shot below, you see a regular pattern for each week over the 30-day period the report covers. From that, it seems the numbers we are seeing associated with each of the days of the graph (e.g. 3.92% (4142) for Tuesday, September 8) is a count of unique visitors just in the context of that one day - i.e. without correlating their uniqueness to the rest of the days in the 30-day period. If the graph actually showed uniqueness across the 30-day period, I would expect the daily numbers to start high in the early days of the period and decrease over the 30-day period as the number of already-seen visitors (i.e. returning visitors) increases, no?
What am I missing here?
UPDATE
Helpful clue from Jonathan S. below got me on the right track.
I think I understand now what the daily bar graph values mean, but it's a little counter-intuitive and I'd bet not what some others might be assuming as well. The reports states "39,822 Absolute Unique Visitors" at the top, which means just that: over the 30-day period we saw this many uniques. Fair enough. The confusing part is that the daily (or weekly) bar values in the graph below are not mutually exclusive uniques as I had assumed, but are values relative only to the 39,822 total - i.e. there is overlap between the unique visitor counts across any group of days. This means the sum of the daily % values > 100% and the sum of the daily count values > 39,822. The algorithm is: when you visit for the first time in the 30-day period, call that "today", you add 1 to the total (39,822) and 1 to the "today" bar value. When you show up again "tomorrow", you are NOT counted again in the total, but ARE counted as 1 in the "tomorrow" bar value.
alt text http://img.skitch.com/20090922-djti81ejj5gqn575ibf8cj1e8x.jpg
I believe it's just an issue of grouping. The top right of the graph has 3 icons to group by day, week, or month. It's currently grouping by day. So if I visit your site today and come back tomorrow, I'll be counted once for each day.
I tried looking at the month view for one of my sites but it didn't give me much meaningful data. I believe the above should answer your original confusion though.
Is it possible that you're searching for something what isn't existing anymore? Unique Visitors/Visits is old terminology. Check: https://www.seroundtable.com/google-analytics-sessions-users-18424.html
Then check how sessions and users are defined:
Sessions ("ex-visits", it's very detailed): https://support.google.com/analytics/answer/2731565?hl=en&ref_topic=1012046
Users in Google Analytics reporting are defined as "Users who have initiated at least one session during the date range". So IMHO it's not about 30 days, it's about the SELECTED date range.
I hope this helps.