A proper feline release scale
1. The Cat's Ass
Working end-to-end product. Python processing, five polished HTML reports, SharePoint publication. Management has seen it.
It works. It's demonstrable. It's worth keeping.
2. The Cat's Paw
Replace the Power Apps metrics dependency with native SharePoint Search Insights exports.
Preserve the working reports. Adapt the data fields as necessary.
One paw forward, four firmly planted.
3. The Cat's Meow
Obtain approved Microsoft Graph access. Demonstrate authenticated Python retrieval of useful SharePoint data.
Verify whether the required search analytics are available through a supported interface.
The cat can talk to Microsoft 365 without a human fetching files.
4. The Cat's Whiskers
Approved Azure Functions deployment. Scheduled collection, processing and report publication. No local workstation dependency.
The product runs, the reports arrive, and nobody needs to know where the machinery lives.
What happened to the Cat's Ass?
The original system works. Its reporting architecture is sound.
The limitation is upstream: Power Apps currently captures the search and click events that populate the SPO Metrics List.
We want to eliminate that application dependency without disturbing the Plays, their metadata, or the reporting system.
SharePoint's native Search Insights provides an alternative source of aggregated search metrics. However, it doesn't necessarily supply the same individual events or identify which specific Plays were clicked.
So the interim solution is a replaceable collection adapter that accepts exported analytics and writes compatible metrics to SharePoint.
That's not rebuilding. That's swapping a component while preserving a functioning product.
And the road to Azure?
Cat's Ass
|
v
Cat's Paw
Native SharePoint metrics
|
v
Cat's Meow
Approved Graph API access
|
v
Cat's Whiskers
Azure Functions deploymentOne caution for the journey: Graph API access is the authentication and integration milestone, not proof that Microsoft's Search Insights dataset is exposed through Graph.
But the guiding principle remains:
Ask. Verify. Demonstrate. Replace.
And at every milestone, the previous version still works.
The road to Azure is paved with Graph API. That's going on the project signpost.
which Plays need better metadata.
First off
The agreed list is:
|
Search metric |
Purpose |
|---|---|
|
Query volume |
Number of searches |
|
Top search queries |
Most frequently searched terms |
|
Abandoned searches |
Searches without a result click |
|
No-result searches |
Searches returning no results |
|
Click-through activity |
Whether users selected a search result |
That's the scope for the demo. No document inventory or metadata exercise.
Project summary: Replacing the metrics data source
Objective
Replace Power Apps as the source of metrics data in an existing, working, end-to-end SharePoint Playbook reporting system.
This is a data-source substitution, not a new application, reporting system, or search engine.
Existing system
-
SharePoint Online hosts the Playbook, including Plays, categories, metadata, and search capabilities.
-
Power Apps currently provides the search interface and captures usage events.
-
A SharePoint Metrics List receives those events.
-
An established reporting pipeline processes the data and generates five HTML management reports covering different reporting periods.
-
The reports are already functioning and have been demonstrated.
The intention is to preserve the working reporting system while replacing its upstream data source.
How people use the Playbook
Users can:
-
View a list of Play Categories.
-
Browse Plays within each category.
-
Open individual Plays.
-
Search for content.
-
Apply search filters, such as restricting results to HTML Plays.
-
Apply other available filters to narrow results.
The Plays already have SharePoint metadata, including search keywords.
Constraints
-
No SharePoint API access to the instance.
-
No assumption that custom code can run inside SharePoint.
-
Limited time available to develop and demonstrate the replacement.
-
Maintainability matters.
-
Existing reports and downstream processing should remain intact.
-
The measurements do not have to be identical to those currently collected by Power Apps, provided they are useful.
The question to investigate
SharePoint already collects search and usage data. What mechanisms are available to capture that data and supply it to the existing reporting system, without SharePoint API access?
There are several potential sources to investigate:
|
Native SharePoint source |
Data potentially available |
Capture mechanism |
|---|---|---|
|
Modern Search Insights |
Query volume, top queries, abandoned queries, no-result queries, result clicks and CTR |
Download Excel reports |
|
Site Usage |
Site visits, unique viewers, popular pages and documents |
Export CSV |
|
Individual page analytics |
Page views, unique viewers, viewing trends |
Native analytics interface; some exports require additional licensing |
|
Microsoft 365 usage reports |
Site-level and user activity |
Admin-centre CSV export, subject to permissions |
|
Microsoft Purview audit |
Document access and other recorded activities |
Audit search/export, subject to permissions and licensing |
Microsoft documents the Search Insights Excel export and Site Usage CSV export.
Unresolved technical questions
-
What does SharePoint actually record? Especially searches, filter selections, category browsing, and HTML Play openings.
-
Which records are accessible? Through native reporting interfaces, exports, or existing administrative facilities.
-
What is the granularity? Individual events, document-level counts, query-level aggregates, or site-wide totals.
-
What identifiers are available? Search text, document URL, category, timestamp, or other fields that could connect observations to Plays.
-
Can the data be captured repeatedly? Without requiring ongoing manual administration or new API permissions.
-
Can the captured data replace the existing metrics feed? Even if the available measurements differ from those originally collected.
Current status
The working system is established. The replacement data source has not been established.
Native SharePoint reporting offers some downloadable data, but we have not demonstrated that it contains sufficient information to replace the existing Power Apps events.
The next investigation is therefore about data availability, granularity, and extraction mechanisms, not reporting or application development.
The central question remains: SharePoint collects the data. How much of it can we get out, and by what supported means?
Another Look after mulling it over
Yes. Here's a summary you can take into the next discussion without having to reconstruct this one.
The Cat's Paw: SharePoint Search and Metrics
Objective
Build a self-sufficient, maintainable SharePoint Playbook using native SharePoint capabilities wherever practical.
The previous implementation relied heavily on Power Apps, including the Playbook front end. Reducing that dependency is a primary objective.
The Playbook will live on the homepage of a SharePoint Online Communication Site.
Self-sufficiency is the primary win. Metrics are a valuable means of evaluating design and implementation success or failure.
Existing working system
- The Playbook contains Plays, categories, documents, and metadata.
- An existing end-to-end metrics reporting system produces five HTML management reports.
- Power Apps currently provides metrics data.
- The reporting pipeline works and should be preserved.
- The data source and available measurements may change.
The Cat's Paw
Replace the Power Apps metrics dependency with native SharePoint data wherever feasible.
Preserve the working reports. Adapt the data fields as necessary.
One paw forward, four firmly planted.
Native SharePoint Search Insights
SharePoint provides five relevant search reports:
- Query Volume: Search activity over time.
- Top Queries: Frequently searched terms, result clicks, and click-through rates.
- Abandoned Queries: Searches that do not lead to result selections.
- No Results Queries: Search terms returning no results.
- Impression Distribution: Distribution of search-result impressions by ranking position.
These provide aggregated measurements suitable for management reporting. Individual user-event logs are not required.
The sandbox reports are currently empty because the sandbox has little real user activity.
Two possible sources of test data:
- Generate representative search actions in the sandbox and allow SharePoint to collect the metrics.
- Obtain native Search Insights exports from the production Playbook site, where real activity exists.
No SharePoint API access is available for this work.
Search experience: A possible larger opportunity
Improving the Playbook's native SharePoint search experience may provide greater value than metrics alone.
Users need to:
- Browse Play Categories.
- View Plays within a category.
- Search for Plays.
- Filter results, including restricting searches to HTML Plays.
- Use additional metadata-based filters where useful.
Search Schema and metadata
SharePoint automatically crawls and indexes supported content and metadata.
Site columns can generate crawled and managed properties. Managed properties may support searching, querying, retrieval, sorting, and refinement, depending on their configuration.
This creates an opportunity to improve how users find Plays by using structured metadata.
The existing schema is not a constraint.
We can add site columns, improve metadata, configure managed properties, and establish useful classifications as required.
The objective is to build a better production solution, not merely preserve existing design decisions.
Potential approach
- Define useful Play metadata and classifications.
- Add or configure SharePoint site columns as needed.
- Establish the corresponding searchable, queryable, and refinable managed properties.
- Use SharePoint's existing search index.
- Provide useful search and filtering through a maintainable SharePoint interface.
- Evaluate the resulting search activity using native SharePoint metrics.
Native SharePoint search must be assessed for its ability to present the desired filters. Search Schema configuration alone does not automatically create a custom search interface.
Engineering constraints
- No direct SharePoint API access.
- Avoid introducing another Power Apps dependency.
- Prefer capabilities the operational team can maintain.
- Preserve the functioning reporting system.
- Change one component at a time.
- Keep the production Playbook usable independently of metrics collection.
Questions for the next investigation
- Which native SharePoint search components can provide the desired Playbook search and filtering experience?
- Which site columns and managed-property configurations would improve Play discovery?
- Can we prioritize HTML Plays and provide useful category or classification filters?
- What actual fields and values appear in the native Search Insights exports once activity exists?
- Can those exports provide a sustainable replacement data source for the existing management reports?
Guiding principle
Build a Playbook the team can sustain. Improve search to help users find the right procedures. Use metrics to evaluate the results.
The Cat's Paw is a controlled evolution of an existing working system, not a redevelopment project.