What the data for this category looks like
This category covers product usage analysis data for operational duty and internal ticket scenarios. Data sources include tracking systems, data warehouses, CRM systems, and ticket systems. Regularly produced documents include usage analysis reports, tracking plans, indicator definition tables, and dashboard requirement forms. Data update frequency is usually daily or weekly. Core fields include feature access frequency, ticket response time, customer operation paths, indicator definition and corresponding units. The data covers cross-customer feature usage behavior, and is used to unify indicator definitions, troubleshoot abnormal data, and explain customer grouping situations.
What constraints these characteristics impose on the sharing and embedding link
Since the data sources include internal sensitive information from multiple systems, the sharing and embedding link must strictly control access permissions to avoid leakage of sensitive ticket and customer data. The data update frequency is daily or weekly, so the embedding link needs to configure a reasonable caching strategy to balance data real-time performance and system request load. Core fields include indicator definitions and units. The original field definitions must be retained after embedding to avoid misjudgments in analysis results. Cross-customer behavior data must be isolated by permissions to ensure that only internally authorized personnel can view analysis content within their corresponding scope.
How to set the configurations
The following configurations are adapted for FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
Sharing entry shareId | Copy the full share link generated by the system, do not replace the identifier manually | Identifies the sharing entry; product usage data analysis business records and data permissions still need to be handled by external systems |
| Share link validity period | Test starting point: 7 days; adjust based on actual product usage data analysis collaboration cycles and revocation requirements | Verify that the link is available within the validity period and access behavior after expiration; this value is not an official default or industry statistic |
| QPM | Test starting point: 20 requests per user per minute; adjust based on actual load | Limits the access frequency of a single user; needs to be verified combined with request logs and actual load |
| Identity verification | When identity permission requirements apply, first check commercial edition capabilities and the uid returned by the third-party identity service | Holding a share link does not equate to having business data permissions; third-party identity and data scope must be verified separately |
| Referenced content display | Select the display configuration of snippets, full text, or original text based on the sensitivity of product usage data analysis materials | Check displayed content within the authorized data scope; do not use hidden interfaces as a substitute for data permission control |
| Conversation record verification | Test example: Prepare 10 product usage data analysis Q&A samples, check them in the same browser and another device respectively | Anonymous records rely on browser local identity; retention cannot be guaranteed across devices or after clearing cache |
Three common mistakes
- Sharing entries related to product usage data analysis fail to open. First check the full system-generated link and its validity period, then cross-check browser request status; do not manually replace
shareId. - The visible scope of product usage data analysis data does not match expectations. Cross-check the third-party identity verification result, workflow request parameters, and external system data permissions respectively; the sharing entry identifier itself does not provide business authorization.
- The same product usage data analysis Q&A cannot be seen on another device. For anonymous scenarios, first check the device, browser, and local identity status; record retention cannot be guaranteed across devices or after clearing cache, do not judge the service as abnormal based solely on this phenomenon.
How to confirm the configuration is complete
- Copy the generated embedding code, paste it into an internal test page, and verify that the operational and ticket analysis data consistent with the original dashboard is loaded.
- Access the generated share link, verify that the returned content includes the expected indicator definitions and field units.
- Attempt to access the share link or embedded page using an identity that has not passed identity verification, verify that the analysis content cannot be loaded normally.
- Wait for the data update cycle set by the external system, refresh the embedded page, and verify whether the data is updated as expected.
The values provided here are common starting points and should be evaluated against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.