We are getting different data for same company post with 2 unique endpoints.
For endpoint - https://api.linkedin.com/v1/companies/4822304/updates/key=UPDATE-c4822304-6378756278751109120/likes?format=json. It is giving 1 like
But when we are hitting historical-status-update-statistics endpoint for stats
https://api.linkedin.com/v1/companies/4822304/historical-status-update-statistics:(like-count,share-count,click-count,engagement,impression-count,time,comment-count)?time-granularity=day&start-timestamp=1517443200000&update-key=UPDATE-c4822304-6378756278751109120&format=json. we are getting 0 like
Here we are fetching the data for the last 3 months, however organisation have made this post 1 month back only it should fetch the lifetime data and should return 1 like.
Related
The bounty expires in 2 days. Answers to this question are eligible for a +50 reputation bounty.
Golak Sarangi wants to draw more attention to this question:
I am also facing a similar issue where the dimensions in the results change based on the metric used. For a certain date range I get 24 cities when I query for totalUsers but 402 cities when I query for sessions.
I'm migrating an app from the Reporting API V4 to the new Data API V1 to support GA4 properties.
While the sessions metric aggregation is usually a few sessions off when adding multiple dimensions or requesting multiple days, adding an event-specific conversions count metric to the report request produces a considerable increase in the number of sessions on the result rows - by a factor of ~4x from my empiric observations.
Request JSON with only the sessions metric and the date dimension:
{"dimensions":[{"name":"date"}],"metrics":[{"name":"sessions"}],"dateRanges":[{"startDate":"2022-12-01","endDate":"2022-12-01"}],"metricAggregations":["TOTAL"]}
Results: 612 sessions on the response row | 612 sessions in Metric Aggregations
Request JSON with the additional conversions:purchase metric:
{"dimensions":[{"name":"date"}],"metrics":[{"name":"sessions"},{"name":"conversions:purchase"}],"dateRanges":[{"startDate":"2022-12-01","endDate":"2022-12-01"}],"metricAggregations":["TOTAL"]}
Results: 2527 sessions on the response row | 612 sessions in Metric Aggregations
Note: this behavior is consistent throughout multiple properties, even for those with no conversions:purchase events.
Is this an API bug, or am I missing something? Is there something I can do to get accurate results?
I've recently added a Google Analytics GA4 tag to a website for the purpose of counting the currently active users. Before, I could see the number of real-time users right now (I think it had a one-minute delay, but I'm not sure).
But in the new GA4, I can only see the number corresponding to 30 minutes, which is not what I needed.
I've looked around and found an option to add a time dimension of 1 minute, but it was for the old google analytics, and it didn't seem right to me.
Not sure if it's needed to provide my code for this question, but if it's a must, then I'll add it.
Edit:
#Run a realtime report to get desired metrics.
def run_realtime_report(property_id):
#Runs a realtime report on a Google Analytics 4 property.
client = BetaAnalyticsDataClient()
#Run the request.
request = RunRealtimeReportRequest(
property=f"properties/{property_id}",
metrics=[Metric(name="activeUsers")],
)
#Parse the response.
response = client.run_realtime_report(request)
...
return activeUsers
#Run the realtime report function.
def run_sample():
global property_id
return run_realtime_report(property_id)
The number of users in the last 30 minutes in GA4 is similar to the "active users on site right now" in Universal Analytics (UA). However after about 5 minutes of inactivity, UA sometimes assesses users are no longer active on the site. This realtime report was generated with pageviews in the last 5 minutes:
After 5 minutes of inactivity, the active users on site goes to zero:
In GA4, you could recreate that calculation by specifying the minutesRange in your realtime report request. This page describes the minuteRange parameter. As a JSON request, this report will only count users who were active in the last 5 minutes:
{
"metrics": [
{
"name": "activeUsers"
}
],
"minuteRanges": [
{
"startMinutesAgo": 5,
"endMinutesAgo": 0
}
]
}
This request is different from GA4 realtime reporting which highlights the "users in last 30 minutes" as the primary realtime metric:
All,
I am trying to pull all data from successfactors using oData API but it give only 1000 rows at a time
How to pull all the data at a time?
Thanks
The OData API can return a maximum number of 1000 records in a single page.
To get the next page of your dataset, you have to call the __next API (which carries a skip token) from previous response. Repeat this action until you get all data via API.
To make a long story short, I need to gather geolocation data and signup date on ~23 million GitHub users for a historical data visualization project. I need to do this within a week's time.
I'm rate-limited to 5000 API calls/hour while authenticated. This is a very generous rate limit, but unfortunately, I've run into a major issue.
The GitHub API's "get all users" feature is great (it gives me around 30-50 users per API call, paginated), but it doesn't return the complete user information I need.
If you look at the following call (https://api.github.com/users?since=0), and compare it to a call to retrieve one user's information (https://api.github.com/users/mojombo), you'll notice that only the user-specific call retrieves the information I need such as "created_at": "2007-10-20T05:24:19Z" and "location": "San Francisco".
This means that I would have to make 1 API call per user to get the data I need. Processing 23,000,000 users then requires 4,600 hours or a little over half a year. I don't have that much time!
Are there any workarounds to this, or any other ways to get geolocation and sign up timestamp data of all GitHub users? If the paginated get all users API route returned full user info, it'd be smooth sailing.
I don't see anything obvious in the API. It's probably specifically designed to make mass data collection very slow. There's a few things you could do to try and speed this up.
Increase the page size
In your https://api.github.com/users?since=0 call add per_page=100. That will cut the number of calls getting the whole user list by 1/3.
Randomly sample the user list.
With a set of 23 million people you don't need to poll very single one to get good data about Github signup and location patterns. Since you're sampling the entire population randomly there's no poll bias to account for.
If user 1200 signed up on 2015-10-10 and user 1235 also signed up on 2015-10-10 then you know users 1201 to 1234 also signed up on 2015-10-10. I'm going to assume you don't need any more granularity than that.
Location can also be randomly sampled. If you randomly sample 1 in 10 users, or even 1 in 100 (one per page). 230,000 out of 23 million is a great polling sample. Professional national polls in the US have sample sizes of a few thousand people for an even bigger population.
How Much Sampling Can You Do In A Week?
A week gives you 168 hours or 840,000 requests.
You can get 1 user or 1 page of 100 users per request. Getting all the users, at 100 users per request, is 230,000 requests. That leaves you with 610,000 requests for individual users or about 1 in 37 users.
I'd go with 1 in 50 to account for download and debugging time. So you can poll two random users per page or about 460,000 out of 23 million. This is an excellent sample size.
I have events module .my user favroite some of random events from listing . i will store them in favroite table of my database
id module
1 events
5 events
9 events
2 business
now , my question how can i make a query to fetch 1,5,9 at single request for event ? is there any way to request it
Yes, you can filter by id to get multiple events in one request, look at the selected answer to this question to learn how to do that. Should work out of the box.