sp-dev-docs
sp-dev-docs copied to clipboard
Page analytics not working
Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
other (enter in the "Additional environment details" area below)
Developer environment
Windows
What browser(s) / client(s) have you tested
- [ ] 💥 Internet Explorer
- [X] 💥 Microsoft Edge
- [ ] 💥 Google Chrome
- [ ] 💥 FireFox
- [ ] 💥 Safari
- [ ] mobile (iOS/iPadOS)
- [ ] mobile (Android)
- [ ] not applicable
- [ ] other (enter in the "Additional environment details" area below)
Additional environment details
Microsoft Edge Version 113.0.1774.42
Describe the bug / error
Target scenario: Read SharePoint page analytics via graph api
Approach: call /analytics/, /analytics/lastSevenDays and /analytics/allTime on site page list item, see https://learn.microsoft.com/en-us/graph/api/itemanalytics-get?view=graph-rest-1.0&tabs=http
Error:
Running in graph explorer
https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{id}/analytics
with list-id being the Site Pages (retrieved via /sites/{site-id}/lists?$filter=displayName eq 'Site Pages'&$select=id)
gives null response
{
"@odata.context": "https://graph.microsoft.com/beta/$metadata#microsoft.graph.itemAnalytics",
"allTime": null,
"lastSevenDays": null
}
/analytics/lastSevenDays,/analytics/allTime gives itemNotFound
https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{id}/analytics/lastSevenDays
{
"error": {
"code": "itemNotFound",
"message": "Item not found",
"innerError": {
"date": "2023-05-17T11:56:00",
"request-id": "210d0197-3baa-4045-8ab5-cd71d3700441",
"client-request-id": "c5c6d732-d977-9be4-6317-48f9c4c97597"
}
}
}
I have double checked permissions (delegated Sites.Read.All) and SharePoint permission levels.
PageViews show up on the page itself - I must do something fundamentally wrong.
This issue came up in https://github.com/SharePoint/sp-dev-docs/issues/8947 and I was recommended to open a new issue.
Steps to reproduce
- Open Graph Explorer https://developer.microsoft.com/en-us/graph/graph-explorer/
- GET
/sites/{site-id}/lists?$filter=displayName eq 'Site Pages'&$select=idto retrieve Site Pages list id (example callhttps://graph.microsoft.com/beta/sites/<company>.sharepoint.com:/sites/<site_name>:/lists?$filter=displayName eq 'Site Pages'&$select=id,displayName - GET https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{id}/analytics (Example:
https://graph.microsoft.com/beta/sites/<company>.sharepoint.com:/sites/<site_name>:/lists/76452593-cead-4f9e-33d2-33a18ef45a91/items/643/analytics
Expected behavior
Response something like
HTTP/1.1 200 OK
Content-type: application/json
{
"allTime": {
"access": {
"actionCount": 123,
"actorCount": 89
}
}
}
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
It seems the itemid should be a guid instead of the index number
Provided list item identifer is not in an allowed format
finding the guid was actually a quest. Still no success.
Tried this
https://graph.microsoft.com/beta/sites/<company>.sharepoint.com,<guid>,<guid>/drives/<driveid>/items/<item-id>/analytics
(looking something like this in real life [I made up the guids etc])
https://graph.microsoft.com/beta/sites/mycompany.sharepoint.com,33831234-451a-4826-b9b5-4212cb64c000,c25cebb1-9f04-41d2-b2a3-d9e44489790d/drives/b!VBKCWRqZJiL5tUIcK2TAQLHrXMIEn9JBsqPJ9Caaaa0jhw73Rj84T7VxssCxIOBS/items/02FIESFL452Z6OXQB7FBF2CDZQNFF6QARX/analytics
and it still gives
HTTP/1.1 200 OK
Content-type: application/json
{
"allTime": {
"access": {
"actionCount": 123,
"actorCount": 89
}
}
}
@TGiersberg -
Try the guid value of etag for list item id in SharePoint site pages. an example https://graph.microsoft.com/v1.0/sites/$siteid/lists/$listid/items/use etag guid/analytics/lastSevenDays
I don't think this is a fix but a workaround that I have found.
Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.
If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.
We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.