Brand analysis method and system based on flow positioning

Abstract

The invention discloses a brand analysis method and system based on flow positioning, and the method comprises the steps: calculating the flow indexes of commodities and search terms based on the total flow data of the commodities under the brand on an e-commerce platform, carrying out the flow abnormality positioning of the commodities and the search terms according to the abnormality judgment rule of each flow index, and carrying out the analysis of the commodities and the search terms based on the flow abnormality judgment result. And carrying out operation abnormity analysis on the brand. The method and the corresponding system can help a brand seller to analyze flow performance of brands, commodities and search terms, realize commodity full-link and brand full-dimension data analysis, locate brand operation problems and hidden dangers, help the brand seller to perform brand analysis and operation, and maintain operation management of stores.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a brand analysis method and system based on traffic positioning, a reconciliation method and system for e-commerce profit reports, a cost recovery method and system based on discrepancies in shipments, and a selection option rendering method and system based on millions of data points. Background Technology

[0002] E-commerce ERP systems (hereinafter referred to as e-commerce ERP) are internet software systems that manage store operations. They typically process tens of millions of orders daily, and the data they manage is extremely complex. Therefore, continuously improving the refined management of stores and increasing store operational efficiency are important goals of e-commerce ERP products during product upgrades and improvements.

[0003] During the brand analysis phase of store operation review, because e-commerce platforms do not provide brand operation data to sellers, brand sellers can only analyze brand performance by summarizing the sales data of each product. This method cannot pinpoint the specific factors affecting sales and will ignore the brand's own impact on sales, thus reducing the accuracy of brand analysis.

[0004] During the profit reconciliation phase of store operation review, the data composition and creation method of e-commerce profit reports are very complex. It is necessary to obtain constantly updated source data from multiple interfaces of the e-commerce platform. Furthermore, the e-commerce ERP also needs to process some of the complex source data, which results in the profit reports after reconciliation still containing a lot of erroneous data.

[0005] During the cost accounting phase of store operation review, the cost of goods is usually calculated based on the purchase cost and first-mile delivery fee. However, when sellers choose to have the e-commerce platform handle logistics (such as FBA) to transport goods, there may be a discrepancy between the number of goods actually received by the e-commerce platform and the number shipped, resulting in differences in the receipt of goods and making the cost of goods in the e-commerce profit report inaccurate.

[0006] When operating the front-end interface for store operation review, the data volume can reach hundreds of thousands or even millions of items, the user operation frequency is high, and there are permission isolation issues. This means that the drop-down selector for data display needs to process massive amounts of data. Conventional drop-down selectors can cause problems such as DOM node explosion, page lag, slow data rendering, and incorrect related data. Ordinary users' computers are unable to complete the rendering of selection items with extremely large amounts of data.

[0007] Other technical issues related to this application will be further elaborated below. The above content is only for assisting in understanding the technical solutions of this application and does not imply that all of the above content is prior art. Summary of the Invention

[0008] The primary objective of this application is to provide a brand analysis method and system based on traffic positioning, which can significantly improve the accuracy of brand analysis. Furthermore, this application also provides a method and system for reconciling e-commerce profit reports, enabling targeted reconciliation of e-commerce profit reports in scenarios involving data changes on e-commerce platforms, missing source data, or errors in data processing by e-commerce ERP systems, thereby significantly improving the accuracy of e-commerce profit reports. Additionally, this application provides a method and system for cost recovery based on discrepancies in shipments, which can compensate for costs lost in transit, improving the accuracy of product costs in e-commerce profit reports. Finally, this application also provides a method and system for rendering selection options based on millions of data points, enabling rendering of selection options under conditions of extremely large data volumes, avoiding query lag and data loss.

[0009] This application proposes a brand analysis method based on traffic positioning for use in the brand analysis module of an e-commerce ERP system. The method includes: Step A1: Obtain the total traffic data of products and search terms under the brand to be analyzed on the e-commerce platform. The total traffic data includes product traffic data in the entire process of placing an order and search term traffic data of products under each search term. Step A2: Calculate the traffic metrics corresponding to the products and search terms based on the total traffic data, and locate traffic anomalies for the products and search terms based on the anomaly judgment rules corresponding to each traffic metric and the products and search terms: The product's traffic metrics include the product's positioning type, lifecycle, exposure, and conversion rate. The product's anomaly determination rules include calculating the current values ​​of exposure and conversion rate based on the product's traffic data, and determining the product's traffic anomalies based on the comparison results between the current values ​​of exposure and conversion rate and the standard thresholds corresponding to the product's positioning type and lifecycle index. The traffic metrics for the search terms include association strength and traffic score. The anomaly determination rules for the search terms include calculating the association strength between each search term and the product based on the search term traffic data, and when the association strength is strong, determining the traffic anomaly of the search term based on the traffic score of each strongly associated search term. Step A3: Based on the traffic anomaly detection results for products and search terms, conduct an operational anomaly analysis for the brand.

[0010] Other features and technical effects of this application will be described in the latter part of the specification. The technical problem-solving approach and related product design scheme of this application are as follows: Brands can effectively influence product sales and have an additional impact on store operations. Therefore, brand sellers need to conduct brand analysis and monitor brand operations. However, e-commerce platforms only provide basic data for individual products, and data silos exist in the backend. Thus, experienced operations personnel can only judge whether a brand is operating normally based on their personal experience. This method cannot achieve a holistic brand analysis. For example, normal changes in product sales may be misjudged as brand anomalies, or changes in sales of products with different brand positioning may occur while the brand's total sales remain unchanged, leading to a misjudgment of normal brand operations despite actual brand anomalies. Furthermore, the applicant discovered during e-commerce activities that search terms can connect buyers and brands, thereby influencing brand operations: on the one hand, buyers can place orders based on search terms; on the other hand, sellers can plan the layout of products in their stores based on changes in search terms on the e-commerce platform. Therefore, when conducting brand analysis, it is necessary to pay extra attention to the impact of search terms on the brand.

[0011] Based on this, the applicant proposes to integrate total traffic data with the brand at its core, conducting cross-analysis of traffic data at both the product and search term dimensions to achieve a comprehensive brand analysis. Specifically, quantified traffic anomaly detection indicators and dedicated anomaly detection rules are established for search terms (association strength and traffic score) and products (positioning type, lifecycle, exposure, conversion rate). This deeply links search terms, products, and the brand, enabling a comprehensive assessment of the brand's operational status and pinpointing the causes of traffic anomalies. Further, at the product level, product positioning is determined by its positioning type and lifecycle, and traffic anomalies are detected based on product exposure and conversion rate. At the search term level, search terms are filtered for associations, and traffic scores are calculated for strongly associated search terms to determine search term traffic anomalies. Additionally, based on the traffic analysis of products and search terms, the brand's own traffic performance is used to determine traffic anomalies, and a comprehensive brand analysis is conducted in conjunction with the traffic conditions of products and search terms, addressing any anomalies within the brand itself.

[0012] In summary, the methods described above help brand sellers analyze product performance, achieve full-chain and multi-dimensional data analysis of products and brands, pinpoint traffic anomalies for products, search terms, and brands, and trace brand operational irregularities. Furthermore, they can establish multi-dimensional bindings between brands, products, and search terms, effectively integrating the complete conversion path from public domain to private domain to repeat purchases, achieving data interoperability, breaking down the data silos and fragmentation issues existing in e-commerce platform backends, improving the efficiency of brand traffic acquisition and competitive advantage on e-commerce platforms, and assisting brand sellers in brand operations.

[0013] Furthermore, this application also provides a method for reconciling e-commerce profit statements for use in the financial module of an e-commerce ERP system. The method includes the following steps: Step S1: Create an e-commerce profit report, which includes sales-related fees, custom fees, platform financial fees, warehousing fees, and initial settlement amount. Step S2: In response to different triggering conditions, execute the corresponding reconciliation logic. If the reconciliation data is inconsistent after executing the corresponding reconciliation logic, the reconciliation is confirmed to be abnormal. The triggering conditions include one or more of the first to fifth triggering conditions and correspond to the reconciliation scenario. When the triggering condition includes the first triggering condition, the first reconciliation logic is executed. The first reconciliation logic is to verify the order data provided by the e-commerce platform and the sales-related fees in the e-commerce profit report. The sales-related fees are order-related fees that affect the actual effective sales volume, including evaluation fees, return fees, and removal fees. The order data are the order amount and order quantity of evaluation orders, return orders, and removal orders obtained from the e-commerce platform. When the triggering condition includes the second triggering condition, the second reconciliation logic is executed. The second reconciliation logic is to verify the seller's custom fee management master table data with the custom fees in the e-commerce profit report. The custom fees include other store fees, other product fees, and monthly fixed fees. The fee management master table data is the fee data used by the seller to manage the store. When the triggering condition includes a third triggering condition, the third reconciliation logic is executed. The third reconciliation logic is to verify the warehousing fee report data provided by the e-commerce platform with the warehousing fees in the e-commerce profit report. The warehousing fee report data is the cost data of the seller for warehousing goods obtained from the e-commerce platform. When the triggering condition includes the fourth triggering condition, the fourth reconciliation logic is executed. The fourth reconciliation logic is to verify the initial settlement amount of the accounts receivable report provided by the e-commerce platform with the initial settlement amount of the e-commerce profit report. The accounts receivable report is an official financial report that records all receivables of sellers on the e-commerce platform, and the initial settlement amount is the amount that the e-commerce platform should pay to the seller at the beginning of the reconciliation period. When the triggering condition includes the fifth triggering condition, the fifth reconciliation logic is executed. The fifth reconciliation logic is to verify the platform financial interface data provided by the e-commerce platform's financial interface with the platform financial expenses in the e-commerce profit report. Step S3: When a reconciliation anomaly occurs, generate an early warning message for the reconciliation anomaly.

[0014] Other features and technical effects of this application will be described in the latter part of the specification. The technical problem-solving approach and related product design scheme of this application are as follows: When reconciling e-commerce profit reports, operators download the original reports from the e-commerce platform and import them into the e-commerce ERP system for reconciliation. However, this method suffers from low accuracy and efficiency. Through repeated practice, the applicant summarized the reasons for the low accuracy of e-commerce profit reports, identifying three scenarios: data changes, missing source data, and errors in data processing by the e-commerce ERP. Based on these three scenarios, the applicant proposes first breaking down the profit composition, then cross-validating the detailed data sources for each data item, and finally tracing the root cause of discrepancies. These data items include sales-related expenses, custom expenses, platform financial expenses, warehousing fees, and initial settlement amounts.

[0015] Specifically, the applicant found that incomplete expenditure coverage and interface transmission errors can lead to missing source data. To address this, using the seller-inputted expense management master table data (i.e., the summary data of management expenses for all seller stores) as source data effectively solves the problem of low reconciliation accuracy in scenarios with missing source data. Furthermore, frequent updates to e-commerce platform data and variations in seller input data can cause data changes. To address this, the applicant proposes comparing each platform financial expense in the e-commerce profit report with the corresponding platform financial interface data to determine if data changes have occurred and adjusting the data items in the e-commerce profit report in real time, thus resolving the problem of low reconciliation accuracy in scenarios with data changes. Moreover, errors in the e-commerce ERP's calculation logic or execution errors can cause errors in data processing by the e-commerce ERP, leading to inaccuracies in the data items in the e-commerce profit report. To address this, the applicant proposes using reconciliation logic response trigger conditions to verify the data items in the processed e-commerce profit report, thus resolving the problem of low reconciliation accuracy in scenarios where the e-commerce ERP's data processing is flawed.

[0016] In summary, this application enables the reconciliation logic to correspond to trigger conditions and the trigger conditions to correspond to scenarios in three scenarios: data changes, missing source data, and errors in data processing by e-commerce ERP systems. By mapping scenarios to reconciliation logic, it verifies the accuracy of each data item in the e-commerce profit report, solving the problem of low accuracy in e-commerce profit report reconciliation. This ensures sellers can manage their stores based on accurate e-commerce profit reports, improving their store management efficiency. Furthermore, this application can monitor the interface status of the e-commerce platform's financial interface, enabling timely updates of abnormal data when data changes occur on the e-commerce platform, thus improving the accuracy of the source data.

[0017] Furthermore, this application also provides a cost recovery method based on discrepancies in shipments, for use in the product cost recovery module of an e-commerce ERP system, the method comprising: Step R1: Traverse the receipt data and shipment data of the shipment within the replenishment period, determine the receipt scenario to which the shipment belongs, and determine whether it is a discrepancy shipment based on the receipt scenario. The receipt scenario of a discrepancy shipment is any receipt scenario other than normal receipt. Step R2: If it is a discrepancy shipment, respond to the user operation on the discrepancy interface and determine the operation type of the user operation; Step R31: When the operation type is a recovery operation, calculate the difference cost of the product corresponding to the recovery operation, and execute the cost recovery logic to recover the difference cost to the e-commerce profit report. The cost recovery logic includes calculating the target product cost of the product corresponding to the recovery operation based on the difference cost, locating the recovery cycle and profit statistics cycle of the product, and recovering the target product cost to the corresponding e-commerce profit report. Step R32: When the operation type is ignored, the initial product cost in the e-commerce profit report is used as the target product cost.

[0018] Other features and technical effects of this application will be described in the latter part of the specification. The technical problem-solving approach and related product design scheme of this application are as follows: When sellers choose FBA for shipment, they may encounter situations where the actual quantity of goods received by the e-commerce platform's warehouse differs from the actual quantity shipped by the seller. In such cases, the cost of the goods changes depending on the receipt status. Based on this, this application proposes to identify receipt scenarios (over-signing, under-signing, missing signing, incorrect signing) based on receipt differences at both the shipment and product levels, and dynamically adjust product costs to accommodate situations where receipt differences cause inaccuracies in e-commerce profit reports under various receipt scenarios.

[0019] During product development, the applicant also discovered that for special products that do not require cost reimbursement (such as goods returned to overseas warehouses by buyers due to incorrect shipments), e-commerce ERP systems directly reimburse the discrepancy costs in the latest profit report. However, this method ignores the seller's intentions and leads to inaccurate e-commerce profit reports obtained in different profit calculation periods. Based on this, this application proposes cost reimbursement based on user actions in the discrepancy interface, and proposes determining the reimbursement period and profit calculation period based on the business time of the goods to be reimbursed, achieving accurate reimbursement and avoiding a chain reaction of errors in multiple e-commerce profit reports due to incorrect reimbursement periods. Furthermore, considering that e-commerce platforms compensate for lost goods, this solution also proposes establishing a linked claim mechanism to jointly adjust product costs based on the platform's compensation amount and the discrepancy costs.

[0020] In summary, this application can efficiently and accurately calculate discrepancies in shipment receipts and link with platform compensation, solving the problem of inaccurate product costs caused by platform compensation and receipt discrepancies. It enables cost confirmation for all products in all shipments, simplifies the cumbersome manual operation process, is compatible with various receipt scenarios, and can be applied to cost recovery for special products, thus improving the accuracy of product costs and making the cost section in e-commerce profit reports more accurate.

[0021] Furthermore, this application also provides a method for rendering selection options based on millions of data points, used in the filtering and display module of an e-commerce ERP system, the method comprising: Step Q1: Determine the visible area of ​​the dropdown selector, and calculate the rendering range of the visible area and the number of selections to be rendered based on the height of the selection and the text length; Step Q2: Create standard nodes based on the number of renders, and fill each standard node with the display content of each initial selection; Step Q3: In response to user actions within the visible area, adjust the displayed content of each standard node, including: Step Q31: In response to the first user operation in the visible area, perform an update operation on the standard nodes, wherein the first user operation is a scrolling operation, and the update operation is to determine the update selection based on the scrolling direction and scrolling distance, match each update selection with each standard node, and update the display content of each standard node. Step Q32: In response to a second user operation in the visible area, perform a mapping operation of the standard node. The second user operation includes a click operation. The mapping operation is to update the selection status of the target selection item corresponding to the second user operation, integrate the selection status and the business information of the target selection item to obtain the virtual node of the target selection item, obtain the identification information of the target selection item, and establish a mapping relationship between the identification information and the virtual node. The identification information can uniquely identify each selection item. The business information includes the inventory status of the product, the order status of the order, and the store identifier to which the selection item belongs. Step Q4: Render each standard node and display the rendered standard nodes in the visible area.

[0022] Other features and technical effects of this application will be described in the latter part of the specification. The technical problem-solving approach and related product design scheme of this application are as follows: In e-commerce scenarios, the data volume of orders, products, and SKUs can reach millions, and user operations are highly interconnected (orders are associated with customers / warehouses / logistics, products are associated with categories / specifications, etc.), placing higher demands on the stable display of e-commerce ERP systems. Generally, dropdown selectors pre-render all data to meet display requirements, but this can lead to excessively long rendering times or even page lag. If only partial data is rendered, due to the unique characteristics of e-commerce data—highly interconnected data and frequent user operations—the data display may be incomplete, or even user operation data may be lost, making it impossible to select or navigate to page functions.

[0023] Based on this, the applicant proposes redefining the visible area of ​​the dropdown selector and rendering a subset of the selections that meet display requirements. The number of options to be rendered is calculated during partial data rendering to balance display quality and rendering time. Furthermore, user actions are monitored, and the data stored in the standard nodes within the visible area for rendering is updated according to the corresponding user action type. This includes scrolling operations (dynamically calculating the rendering data of the visible area based on scrolling direction and distance) and click operations (using the selected state and business information of the options as virtual nodes and establishing a mapping relationship between virtual nodes and option identifiers). While updating the data, the number of DOM nodes (i.e., standard nodes) remains unchanged, only updating the internally populated option data to achieve data feedback and avoid mapping loss. Addressing the specific characteristics of e-commerce data, the applicant, based on experience in e-commerce practice, proposes performing data association operations, including hierarchical association, business association, and dependency association, and configuring the dropdown selector options to be displayed in a hierarchical manner based on the association relationships. Specifically, the relationships, storage, and rule definitions should be completed in advance at the data and configuration layers, including defining irreversible hierarchical nodes, defining related fields and display rules, and defining dependency types and dependency mappings.

[0024] In summary, this application meets the display requirements of e-commerce ERP systems in scenarios with extremely large data volumes and high-frequency operations. It solves the problems of query lag and status data loss when displaying millions of data points, optimizing and improving e-commerce ERP systems from unusable (frozen) to having a response time of seconds in data scenarios exceeding one million. It also achieves a smooth scrolling and instant response user experience, avoiding freezing during operations such as selecting all, reducing the consumption of computing resources, and enabling visual browsing of the entire dataset in real-world business scenarios while maintaining a response time of seconds.

[0025] Other implementation schemes and their technical effects will be described later.

[0026] Furthermore, this application also includes systems corresponding to various methods. These systems contain the functional modules involved in this application, execute operation instructions for the corresponding functional modules or methods, and output relevant data information to the system front-end interface. The system is stored in a server and / or computer device containing a processor, which executes the system's operation instructions.

[0027] Declaration: The functional modules of this application can be integrated with each other, or they can exist independently, or one functional module can be a sub-module of another functional module; the step numbers do not limit the order of the corresponding operation steps.

[0028] The following is a description of the relevant terms used in this application.

[0029] ASIN refers to the product ID on the Amazon platform, and in this application, it can be used to refer to the product ID on e-commerce platforms in general.

[0030] FBA refers to an e-commerce platform's dropshipping service model, where sellers prepare goods in advance in FBA warehouses, and the e-commerce platform handles the dropshipping when an order is placed.

[0031] Reconciliation period: The time interval for verifying the accuracy of profit data, used to check the consistency between the calculation results and the source data.

[0032] Settlement cycle: The period from when a seller completes a sale to when payment is received on an e-commerce platform.

[0033] Profit statistics period: The time boundary for calculating profits, defining the period to which profit data belongs. Attached Figure Description

[0034] The accompanying drawings are provided to further understand this application and do not constitute a limitation thereof; the content shown in the drawings may be actual data of the embodiments and falls within the protection scope of this application.

[0035] Figure 1 This is a schematic diagram illustrating the principle of a brand analysis method based on traffic positioning in one embodiment of this application.

[0036] Figure 2 This is a schematic diagram of a user-side visualization in one embodiment of this application.

[0037] Figure 3 This is a schematic diagram illustrating the principle of the reconciliation method for e-commerce profit statements in one embodiment of this application.

[0038] Figure 4 This is a schematic diagram illustrating the principle of synchronous verification in one embodiment of this application.

[0039] Figure 5 This is a schematic diagram illustrating the principle of a cost recovery method based on discrepancies in shipments in one embodiment of this application.

[0040] Figure 6 This is a flowchart illustrating the process of determining receipt status in one embodiment of this application.

[0041] Figure 7 This is a flowchart illustrating a selection option rendering method based on millions of data points in one embodiment of this application.

[0042] Figure 8 This is a schematic diagram of the visible area of ​​a drop-down selector in one embodiment of this application. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0044] In one embodiment, the e-commerce ERP system of this application includes one or more functional modules such as a product module, a brand analysis module, a financial module, a product cost recovery module, a filtering and display module, a permission management module, and a data module. These functional modules can be integrated with each other, exist independently, or one functional module can be a sub-module of another functional module.

[0045] refer to Figures 1-2 This application proposes a brand analysis method based on traffic positioning. In one embodiment of this application, the method includes steps A1-A3, as follows.

[0046] Step A1: Obtain the total traffic data of products and search terms under the brand to be analyzed on the e-commerce platform. The total traffic data includes product traffic data in the entire process of placing an order and search term traffic data of products under each search term.

[0047] The total traffic data for products and search terms under a brand is collected from the API interface of the e-commerce platform. Product traffic data is product-level search interaction data, such as impressions, clicks, add-to-cart and purchases. The data format is [brand, ASIN (i.e., product), search performance (impressions, clicks, add-to-cart, etc.)]; search term traffic data is the top-ranking search queries for a specific ASIN, that is, the performance of the product under different search terms. The data format is [ASIN / brand, search term, traffic performance (search volume, search rating, search term ranking), search performance (impressions, clicks, add-to-cart, etc.)].

[0048] In one embodiment, a three-layer analysis structure is established based on total traffic data, namely: Product Dimension View: integrating the entire link data of ASIN's exposure / click / add to cart / purchase; Search Term-ASIN View: analyzing the traffic performance of a single ASIN under a search term; Search Term-Brand View: summarizing the traffic performance of all products under a brand and analyzing the overall brand performance under the search term.

[0049] Visual charts are generated based on total traffic data. These charts include a trend chart showing the time-based metrics for product orders (filtered by time), a conversion funnel chart showing the entire order process, a search term table displaying search terms and product share, and a conversion percentage pie chart showing the contribution of each search term to the total order volume. The time-based metric trend chart represents the ratio of a product's traffic metrics within a selected time period (selected at different time granularities, such as week, month, quarter, etc.) to the total value of that product within the total statistical time period (e.g., one year). The nodes of the conversion funnel chart are sequentially linked: exposure corresponds to the top-level entry data of the funnel, clicks correspond to the conversion output data of the exposure node, add-to-cart data corresponds to the conversion output data of the click node, and order volume corresponds to the conversion output data of the add-to-cart node. The search term table shows the traffic situation of a product under each search term and its share in the traffic pool of that search term within the selected time period. The conversion percentage pie chart shows the percentage of converted orders for each search term within the order volume of a product.

[0050] Step A2: Calculate the traffic metrics corresponding to the products and search terms based on the total traffic data, and locate traffic anomalies for the products and search terms based on the anomaly judgment rules corresponding to each traffic metric and the products and search terms: The product's traffic metrics include the product's positioning type, lifecycle, exposure, and conversion rate. The product's anomaly determination rules include calculating the current values ​​of exposure and conversion rate based on the product's traffic data, and determining the product's traffic anomalies based on the comparison results between the current values ​​of exposure and conversion rate and the standard thresholds corresponding to the product's positioning type and lifecycle index. The traffic metrics for the search terms include association strength and traffic score. The anomaly determination rules for the search terms include calculating the association strength between each search term and the product based on the search term traffic data, and when the association strength is strong, determining the search term for traffic anomalies based on the traffic score of each strongly associated search term.

[0051] Obtain the exposure volume of each product and determine whether the value and changes in the exposure volume fall within an abnormal range; if so, confirm that the product exposure is abnormal; construct a conversion funnel based on the product traffic data, showing the entire process of product ordering (i.e., the entire process from exposure to click to add to cart to order), calculate the product conversion rate based on the conversion funnel, and confirm that the product conversion is abnormal when the conversion rate is lower than the corresponding standard threshold. The entire process node refers to the entire process from exposure to click, then to add to cart and finally to order; the positioning type refers to the attribute tags of each product in the brand, including traffic-driving products, profit-generating products, image-building products, and long-tail products; the lifecycle refers to the operational cycle of the product from listing to delisting, including the introduction stage, growth stage, maturity stage, and decline stage; the conversion rate is the ratio of product exposure, click, add to cart, and order, including click-through rate, click-to-add-to-cart rate, add-to-cart-to-order rate, and overall conversion rate; when a product shows abnormal exposure and / or abnormal conversion, confirm that the product traffic is abnormal. Furthermore, the product traffic data is stratified based on delivery type to obtain product traffic data for each delivery type. These delivery types include same-day delivery, next-day delivery, and standard delivery. The stratification of delivery time involves dividing the product traffic data into three parts based on the delivery type. In other words, by splitting the product traffic data according to delivery type, we can determine the differences in ASIN preferences among users with different delivery needs, analyze the impact of fast delivery on traffic conversion, and accurately pinpoint operational shortcomings related to delivery time.

[0052] In one embodiment, the seller defines the product's positioning type when listing the product and determines the product's lifecycle based on the length of time the product has been listed. The standard threshold is not a fixed value, but a threshold library composed of combinations of positioning type and lifecycle. Each product has its own unique judgment criteria. The judgment indicators for the product's positioning type include: average order value, gross profit margin, sales contribution, traffic attributes, delivery timeliness, and customer reviews. For example, for a traffic-driving product in the introductory phase, the listing time is ≤30 days, and the required exposure is ≥20,000 and the conversion rate is ≥8%. The characteristics of a traffic-driving product are high sales volume and low gross profit (e.g., sales volume within the period accounts for ≥20% of the brand's total sales volume, and the gross profit margin is ≤15%). In practical applications, the specific thresholds and ranges are determined by the seller based on the brand and product positioning. When the current value of a product is less than the critical standard threshold, the product traffic is confirmed to be abnormal.

[0053] To reduce ineffective operational actions, abnormal traffic alerts are only issued for search terms related to the product. The association strength between the product and each search term is calculated. The dimensions of this association strength calculation include the semantic matching degree of the similarity between the search term and the product keywords, the conversion relevance of the search term to the conversion rate of orders placed with the product, and the intent matching degree of the search term to the product's category. It is then determined whether the association strength is strong. If so, the traffic score for each strongly associated search term is calculated. If the traffic score is lower than a threshold, abnormal search term traffic is confirmed. The traffic score refers to the degree of relevance of the search term's traffic changes to the brand and its impact on the brand. Specifically, the semantic matching degree is obtained by calculating the field similarity between each search term and each product description data (i.e., the product description on the product details page, including product specifications, color, use, material, etc.); the intent elements of each search term are decomposed and matched with the product categories of each product; the intent matching degree of each search term is calculated based on the weighted value of each category element; the conversion rate, abnormal conversion ratio, and order path length of each product under each search term are calculated based on the search term-product data in the search term traffic data, and the conversion relevance is calculated based on the corresponding conversion weight. The search term-product data is the data of a single product under the search term, and the search term traffic data also includes search term-brand data, which summarizes the brand dimension data of all products under the brand.

[0054] The correlation strength is a numerical value that measures the matching degree and value binding between a product and a search term, including strong correlation, medium correlation, and weak correlation. Only search terms with a strong correlation strength can be included in the traffic anomaly judgment to avoid interference from irrelevant words. Its calculation dimensions include: intent matching degree (the degree of fit between the search term and the product category), semantic matching degree (the degree of semantic fit between the search term and the product's core selling points / keywords), conversion relevance (the ability of the search term to convert product search results into orders), etc. The traffic score refers to the degree of correlation between the search term's traffic changes and the brand, as well as the degree of influence on the brand. It is a comprehensive quantification of the quality and effect of the current traffic of the search term, avoiding misjudgment caused by looking at a single indicator.

[0055] Based on traffic analysis of products and search terms, the system identifies traffic anomalies by examining the brand's own traffic performance. Furthermore, it conducts a comprehensive analysis of the brand, considering both product and search term traffic patterns. The traffic scoring dimensions include traffic scale, conversion quality, traffic share, and traffic stability. Traffic scale refers to the size of the traffic pool containing the search term; conversion quality refers to the search term's order conversion rate; traffic share refers to the brand's share of the search term's traffic pool; and traffic stability refers to the search term's ability to consistently generate traffic. The system calculates the search term's score across these dimensions, defines the scoring weights for each dimension, and calculates the sum of the products of each score and its corresponding weight to obtain the search term's traffic score. The traffic score is calculated as follows: Traffic Score = (Traffic Scale Score × α1) + (Conversion Quality Score × α2) + (Traffic Share Score × α2) + (Dynamic Stability Score × α4), where α1, α2, α3, and α4 are scoring weights, and their sum is 1.

[0056] Additionally, reward and penalty items can be added to the traffic scoring calculation process. The reward item, with a value of (0, 0.2), is used to positively incentivize high-value features and is the sum of core keyword matching rewards, high-growth rewards, and low-fluctuation rewards. The penalty item, with a value of (0, 10), is used to negatively deduct low-value features and is the sum of invalid click penalties, high-competition penalties, lifecycle penalties, and policy risk penalties. In summary, this approach considers the scale, conversion, proportion, and stability of traffic, avoiding the limitations of a single indicator and helping brands select precise traffic, thus meeting the core needs of brand analysis.

[0057] Step A3: Based on the traffic anomaly detection results for products and search terms, conduct an operational anomaly analysis for the brand.

[0058] In addition, based on the traffic analysis of products and search terms, the brand's own traffic performance is used to determine traffic anomalies. Furthermore, based on these anomalies, a comprehensive analysis of the brand is conducted, combining the traffic status of products and search terms. Specifically, the brand traffic data of the brand to be analyzed (focusing on the brand's performance for each keyword) is obtained. The traffic performance of the brand to be analyzed is calculated. This brand traffic data includes driving traffic data brought by the brand to its products (traffic actively attracted by the brand to attract buyer clicks and visits, including brand keyword search traffic, brand store traffic, repeat purchase traffic from existing customers, and targeted traffic from brand advertising) and lost traffic data due to competitors (potential traffic that might have originally belonged to the brand but was taken away by competitors, including traffic from the brand's core keywords being taken by competitors, traffic from the target customer group being intercepted by competitor advertising, and buyer diversion caused by competitor price reductions or promotions). The traffic performance is the sum of the current values ​​of driving traffic data and lost traffic data and their corresponding traffic weights. Based on the traffic performance of the brand to be analyzed, traffic anomalies are determined, and based on the results of the traffic anomaly determination for products, brand, and search terms, operational anomaly analysis is conducted for the brand.

[0059] The first-level judgment is performed based on the brand's traffic performance. This first-level judgment includes: a first judgment logic where, if brand traffic anomalies are confirmed based on traffic performance, a second-level judgment is initiated; or a second judgment logic where, if brand traffic performance confirms a slight anomaly, and at the product level, the proportion of products with abnormal traffic under the brand with slight anomalies is greater than 1 / 3 of all products under that brand, or at the search term level, if the search term traffic score confirms abnormal traffic under the brand with slight anomalies, a second-level judgment is initiated based on the traffic performance of both products and search terms. This second-level judgment includes: after the first judgment logic is completed, if the proportion of products with abnormal traffic under the brand with abnormal traffic is greater than 1 / 3 of all products under that brand, a second-level judgment is initiated. If one-fifth of all products under a brand exhibit abnormal traffic, and the search term's traffic score confirms abnormal traffic, then the brand operation is confirmed to be abnormal. Alternatively, after the first judgment logic is executed, if the sum of the number of products with abnormal traffic and slightly abnormal traffic under a brand exceeds half of all products under that brand, then the brand operation is confirmed to be abnormal. Alternatively, after the first judgment logic is executed, if the competitor's influence is ≥0.8 and the brand's driving force is ≤0.2, then the brand operation is confirmed to be abnormal. After the second judgment logic is executed, if the number of products with slightly abnormal traffic under a brand exceeds two-fifths of all products under that brand and the number of search terms with abnormal traffic exceeds half of all search terms, then the brand operation is confirmed to be abnormal.

[0060] Furthermore, after confirming that the brand has operational anomalies, a corresponding operational adjustment plan is proposed: When product traffic is abnormal, the positioning system is reconstructed based on the product lifecycle and positioning type, and a mechanism for rectifying and handling abnormal products is established. For products with abnormal exposure, the advertising budget is shifted to high-ROI channels for precise targeting and improved exposure and conversion efficiency. For products with abnormal conversion, the first screen of the product details page is optimized to lower the decision-making threshold. A rectification period is set, and if the exposure / conversion still does not meet the target after rectification, the inventory ratio is reduced or the removal process is initiated. When brand traffic is abnormal, if brand loyalty is ≤0.3, a tiered membership system is built to increase repurchase frequency. If brand drive is ≤0.2, the search pull of brand keywords is strengthened, and the core brand value is highlighted on the official website and e-commerce details page. If the competitor's influence is ≥0.8, the core advantages of the competitor are first analyzed, and a dual product line of high-end + cost-effective sub-line is launched, or additional services are highlighted, or new channels are explored, and comparative ads are placed on the competitor's core channels. When search term traffic is abnormal, the reasons for the decline in keyword traffic are analyzed, content is created around the core search terms and product links are embedded, a daily monitoring table for core keywords is established, and keywords are replaced with high-potential keywords with similar semantics.

[0061] In summary, this solution helps brand sellers analyze traffic performance for brands, products, and search terms, enabling full-link and multi-dimensional data analysis of products and brands. It also helps pinpoint brand operation issues and potential risks, assisting sellers in brand analysis and operation, and maintaining store operational management. Furthermore, it abandons the reliance on single sales volume as the data foundation for brand analysis, and is compatible with brand analysis scenarios where individual product sales remain unchanged or fluctuate, or where total sales of products under a brand remain unchanged or fluctuate. This avoids inaccurate brand analysis due to a single determining factor.

[0062] refer to Figures 3-4 This application also provides a method for reconciling e-commerce profit statements for use in the financial module of an e-commerce ERP. In one embodiment of this application, the method includes steps S1-S3, as follows.

[0063] Step S1: Create an e-commerce profit report. The e-commerce profit report includes sales-related fees, custom fees, platform financial fees, warehousing fees, and initial settlement amount.

[0064] The system retrieves warehousing fee reports and accounts receivable reports from different reporting interfaces of the e-commerce platform, and order data (evaluation orders, return orders, and removal orders) from the order interface. It also receives seller input to obtain the main expense management table data. Integrating these data, the system obtains non-interface data from the source data for generating the e-commerce profit report. This data is then allocated and aggregated to obtain sales-related fees, custom fees, warehousing fees, and initial settlement amounts for the e-commerce profit report. Finally, it retrieves platform financial interface data (i.e., interface data) from the e-commerce platform's financial interface, and allocates and aggregates this data to obtain platform financial expenses. This allocation and aggregation involves distributing the store's costs or revenue to different objects (products, stores, etc.) according to preset allocation rules, and then summarizing upwards to obtain the e-commerce profit report at the target level (product dimension, store dimension, ASIN dimension, store summary dimension, etc.).

[0065] In one embodiment, to avoid data transmission errors between the e-commerce platform and the e-commerce ERP due to interface anomalies, the interface status of the financial interface is monitored and the completeness and accuracy of the platform's financial interface data are verified based on the synchronization verification results. The platform's financial interface data includes platform payments (the order amount paid by the e-commerce platform to the seller after the order is completed), beginning balance (the balance carried forward from the previous settlement cycle), reserved amount (the amount reserved by the seller on the e-commerce platform for handling claims or non-payment situations), sales revenue, buyer shipping costs, etc. Settlement report data is obtained from another reporting interface of the e-commerce platform (the settlement report data corresponds to the platform's financial interface data but has a different presentation format); synchronization verification rules are defined for each field in the platform's financial interface data and the settlement report data, and the corresponding fields in the platform's financial interface data and the settlement report data are synchronously verified according to the synchronization verification rules. Specifically, the platform repayment field is defined as the highest priority, the beginning balance field and the reserved amount field as medium priority, and the remaining fields in the platform financial interface data as the lowest priority. The field values ​​of the platform repayment field in the settlement report data and the platform financial interface data are determined, and the field values ​​are synchronously checked to determine if they are consistent. If the field values ​​are consistent, the synchronous check result is confirmed to be normal. If the field values ​​are inconsistent, the field values ​​of the beginning balance field and the reserved amount field are synchronously checked to determine if they are consistent. If all field values ​​are consistent, the field with the highest priority is integrated to generate a synchronous check anomaly result. If at least one field value is inconsistent, the names of all inconsistent field values ​​are integrated to generate a synchronous check anomaly result.

[0066] Step S2: In response to different triggering conditions, execute the corresponding reconciliation logic. If the reconciliation data is inconsistent after executing the corresponding reconciliation logic, the reconciliation is confirmed to be abnormal. The triggering conditions include one or more of the first to fifth triggering conditions and correspond to the reconciliation scenario.

[0067] When the triggering condition includes the first triggering condition, the first reconciliation logic is executed: The order data provided by the e-commerce platform is compared with the sales-related fees in the e-commerce profit report. These sales-related fees are order-related expenses that affect actual effective sales volume, including evaluation fees, return fees, and removal fees (destruction fees for destroyed orders and disposal fees for removed orders). The verification dimensions are the store summary dimension and the store dimension. The order data includes the order amount and quantity of evaluation orders, return orders, and removed orders (i.e., unsellable orders) obtained from the e-commerce platform. The verification process is as follows: Verify the evaluation fees (or return fees) of all stores within the reconciliation period; if there is a discrepancy, verify the evaluation fees (or return fees) of each store. Specifically, the process involves calculating the total store evaluation fee (or total store return fee) based on the store-level evaluation fee (or store-level return volume and return fee) in the e-commerce profit report, and calculating the total order amount of evaluation orders (or return orders) in the order data. The process then verifies the total store evaluation fee (or total store return fee) against the total order amount of the evaluation orders (or total order amount of return orders). If the values ​​match, the reconciliation is considered normal. If the values ​​do not match, the process calculates the evaluation order amount (or return order amount) for each store in the order data, and verifies the store-level evaluation fee (or return fee) against the corresponding evaluation order amount (or return order amount). If both values ​​match, the reconciliation is considered normal; otherwise, the reconciliation is considered abnormal. Additionally, the process verifies the destruction volume (or removal volume) for all stores within the reconciliation period. If there is a discrepancy, the process verifies the destruction volume (or removal volume) for each store, and confirms whether the destruction fee (or disposal fee) is reconciled correctly based on the verification results of the destruction volume. Specifically, the destruction volume at the store level in the e-commerce profit report is summarized to obtain the total destruction volume for each store; the total destruction volume of destroyed orders in the order data is calculated; the total destruction volume for each store and the total destruction volume of destroyed orders are verified; if the values ​​are consistent, the destruction fee reconciliation is considered normal; if the values ​​are inconsistent, the destruction volume for each store's destroyed orders in the order data is calculated, and the destruction volume at the store level and the destruction volume of destroyed orders are verified separately; if the two values ​​are consistent, the destruction fee reconciliation is considered normal, otherwise, the reconciliation is considered abnormal; similarly, the disposal fee in the e-commerce profit report is verified. In addition, a predefined error tolerance rule for the reconciliation results is defined, that is, the ideal state is that the values ​​are completely equal, and if there is a slight deviation, as long as the deviation value is ≤ the preset error neglect value, it is considered that the verification has passed.

[0068] When the triggering condition includes the second triggering condition, the second reconciliation logic is executed: The seller's custom fee management master table data is compared with the custom fees in the e-commerce profit report. The custom fees include one or more of the following: other store fees, other product fees, and monthly fixed fees. The data in the fee management master table corresponds to each fee in the custom fees. Other store fees are variable expenses incurred in the store's daily operations that cannot be categorized into other core expense items, such as annual fees for store platform entry and language translation fees for cross-border stores. Other product fees are expenses incurred by specific products and directly related to product production, packaging, and after-sales service, such as product sample quality testing fees. Monthly fixed fees are continuous expenses that do not fluctuate with sales volume, occur monthly, and are directly related to e-commerce operations. The total amount of each fee in the custom fees of all stores within the reconciliation period is verified. If there is a discrepancy, the individual fees in the custom fees of each store are verified. Specifically, when the custom fees include other store fees, the other store fees in the store dimension of the e-commerce profit report are summarized to obtain the total other store fees, and the total other store fees in the main expense management table are calculated; the total other store fees are then compared with the total other store fees; if the values ​​match, the reconciliation is considered normal; if the values ​​do not match, the other store fees in the store dimension and the other store fees of each store in the main expense management table are compared separately; if the two values ​​match, the reconciliation is considered normal, otherwise the reconciliation is considered abnormal; similarly, when the custom fees include other product fees and / or monthly fixed fees, the other product fees and / or monthly fixed fees are compared. Furthermore, the verification dimensions for custom fees are the monthly dimension, the store summary dimension, and the store dimension.

[0069] When the triggering condition includes a third triggering condition, the third reconciliation logic is executed. This third reconciliation logic involves verifying the warehousing fee report data provided by the e-commerce platform against the warehousing fees in the e-commerce profit report. The warehousing fees include monthly warehousing fees and long-term warehousing fees. The warehousing fee report data is the cost data obtained from the e-commerce platform for sellers' goods warehousing expenses. The monthly warehousing fee report data is affixed and summarized to obtain monthly warehousing fee data at the store level and monthly warehousing fee data at the product level. The monthly warehousing fee data at the store level in the e-commerce profit report is then verified against the monthly warehousing fee report data at the store level. If the values ​​match, the reconciliation is considered normal. If the values ​​do not match, the monthly warehousing fee data at the product level in the e-commerce profit report is verified against the monthly warehousing fee data at the product level. If the values ​​match, the reconciliation is considered normal; otherwise, the reconciliation is considered abnormal. Similarly, the long-term warehousing fees are verified. Specifically, the monthly storage fee reports are assigned to the corresponding products to obtain a product-level monthly storage fee report. These product-level monthly storage fee reports are then summarized to obtain a store-level monthly storage fee report. The total amount of each expense in the storage fees for all stores within the reconciliation period is verified. If discrepancies are found, the individual expenses in the storage fees for each store are verified. The verification dimensions for storage fees are store-level and product-level.

[0070] When the triggering condition includes the fourth triggering condition, the fourth reconciliation logic is executed. This fourth reconciliation logic involves verifying the initial settlement amount in the accounts receivable report provided by the e-commerce platform against the initial settlement amount in the e-commerce profit report. The initial settlement amount is the amount the e-commerce platform owes to sellers at the beginning of the reconciliation period. Specifically, comparing the values ​​of different calculation formulas for the initial settlement amount, the initial settlement amount in the e-commerce profit report is the total of the month-end balance, the period increase, and the amount transferred at the beginning of the month. The initial settlement amount in the accounts receivable report is the balance at the end of the previous month. The period increase is the total amount of seller revenue, buyer refunds, and seller expenses for the current period. The accounts receivable report is an official financial report recording all receivables (including settlement details, fee deductions, etc.) of sellers on the e-commerce platform, used to clarify the amount the platform owes to sellers. The verification of the initial settlement amount only verifies the amounts for the previous two months, and the verification dimension is the store level.

[0071] When the triggering condition includes the fifth triggering condition, the fifth reconciliation logic is executed. This fifth reconciliation logic involves verifying the platform financial interface data provided by the e-commerce platform's financial interface against the platform financial expenses in the e-commerce profit report. Specifically, it determines the field mapping relationship between the platform financial expenses in the e-commerce profit report and the platform financial interface data, and verifies the field values ​​of the platform payment return field in the platform financial expenses and the platform payment return field in the platform financial interface data. If the values ​​match, the reconciliation is considered normal; if the values ​​do not match, the reconciliation is considered abnormal, and the remaining fields of the platform financial expenses are verified against the corresponding fields in the platform financial interface data based on the field mapping relationship to identify the abnormal fields. Additionally, it is necessary to verify the same user code (PUID) and shop code (shop_id) sub-data in the platform financial expenses and platform financial interface data, using the original currency for numerical verification, excluding numerical signs such as positive and negative numbers. The value retrieval logic for the platform payment return field in the platform financial expenses is the sum of all field values.

[0072] Furthermore, the fifth triggering condition involves verifying the month, user identifier, store name, and manually refreshed historical e-commerce profit reports. The reconciliation period begins on the 3rd of each month, verifying all stores marked as unverified or failing verification (excluding the previous month). The previous month's e-commerce profit report is verified three times this month: on the 5th, 10th, and 20th. In one embodiment, the first to fourth reconciliation logics verify the expenses in the e-commerce profit report that correspond to non-interface data in the source data. In this case, the triggering condition includes aggregating non-interface data to obtain the e-commerce profit report within the reconciliation period. The triggering conditions for specific expense fields depend on the specific scenario. Triggering conditions include both scenario and time. This application does not limit the number of triggering conditions in each scenario. For example, in a scenario where source data is missing, there may be one or all triggering conditions, thereby initiating one or all reconciliation logic verifications for the expense fields in the e-commerce profit report.

[0073] In one embodiment, this solution proposes to address the discrepancy between profit reports and source data during reconciliation using timestamps, ensuring traceability and data location. Specifically, the source data used to create e-commerce profit reports is collected with timestamps and then standardized for time. The timestamps include the data collection time (the time data is collected from the e-commerce platform backend or e-commerce ERP), the business node time (the actual time the business occurred), and the data synchronization time (the time the source data is synchronized from the collection point to the e-commerce ERP). The time standardization process includes unified time format, timestamp binding (strongly binding each source data entry to a timestamp), and time granularity division (dividing time granularity according to reconciliation requirements, such as daily, weekly, and monthly levels). Source data is filtered based on the seller's target time granularity and target reconciliation cycle to obtain a reconciliation source data pool. Based on the data in the e-commerce profit reports… The system executes corresponding reconciliation logic, verifies the e-commerce profit report and the reconciliation source data pool, and records the reconciliation time. When a reconciliation anomaly occurs, it locates the abnormal data item and its corresponding source data, generating a timestamp traceability chain. This chain is arranged chronologically as follows: data collection time, business node time, data synchronization time, and reconciliation time. The system drills down the timestamp traceability chain according to the target time granularity, outputting a drill-down list (including the reconciliation amount, difference amount, and timestamp of the abnormal data item at the corresponding granularity). Based on the drill-down list, it determines the abnormal time type of the abnormal data item, which includes source data timestamp errors, source data cross-period attribution errors, and source data synchronization errors. In summary, this system can quickly locate time-related reconciliation anomalies, significantly improving reconciliation efficiency and accuracy.

[0074] Step S3: When a reconciliation anomaly occurs, generate an early warning message for the reconciliation anomaly.

[0075] The system retrieves exception information (including verification time, user identifier, and exception fields) corresponding to abnormal execution of reconciliation logic, and generates early warning information based on the exception information and preset early warning templates (including table templates and notification templates). On one hand, the exception information combined with the notification template yields a notification-style early warning message. The reconciliation error format for the expense fields in the e-commerce profit report includes the monitored item, node address, alarm service, and alarm content. On the other hand, the exception information combined with the table template yields a table-style early warning message. The error format for synchronization verification anomalies when platform financial interface data and settlement report data are synchronized includes the verification time, user code, settlement name (settlement ID), verification field, and exception field. When the first to fourth reconciliation logics are executed and a reconciliation anomaly occurs, the reconciliation error format is: reconciliation time, user code, verification granularity (store / order / product), field, original dimension value, verification dimension value, and difference. When the fifth reconciliation logic is executed and a reconciliation anomaly occurs, the reconciliation error format is: reconciliation time, user code, store, field, currency, platform financial interface data, and platform financial expense.

[0076] Furthermore, the e-commerce ERP of this application also includes an interface management module. This module pre-configures the various interfaces of the e-commerce ERP to connect with external interfaces such as e-commerce platform interfaces and logistics provider interfaces, thereby obtaining relevant data. To improve interface configuration efficiency and reduce the amount of code programming during the connection process, this application also proposes an interface configuration method based on common interfaces for connecting the e-commerce ERP to e-commerce platform interfaces or logistics provider interfaces. Taking the connection to a logistics provider system as an example, the interface configuration method based on common interfaces of this application includes the following steps B1-B6.

[0077] Because the specifications of logistics provider interfaces vary greatly and there is a lack of unified standards among different logistics provider systems, when connecting to logistics interfaces, the corresponding interface is usually configured separately for each logistics provider system (the system being connected) in the connecting system (e-commerce ERP). This requires developers to write a lot of code, resulting in low integration efficiency and difficulty in upgrading and maintaining the interface.

[0078] Step B1: Create a connection table to record basic information for each logistics provider's interface. This basic information includes the logistics provider identifier, logistics provider interface identifier, interface request address, interface request parameters, parameter mapping rules, and policy rule item identifiers. The basic information for each logistics provider's interface is created as a corresponding basic information group. Specifically, interface request parameters refer to the interface parameters corresponding to the request task for each interface type (including authorization verification interface, logistics order creation interface, logistics tracking number retrieval interface, logistics waybill retrieval interface, and logistics fee retrieval interface, etc.) during interface connection. Parameter mapping rules refer to the correspondence between field parameters in the connection system and field parameters in the logistics provider's system. Furthermore, the connection table can be set to an editable state, and information for multiple logistics provider interfaces that need to be connected can be pre-entered into the connection table to achieve batch configuration of the connected interfaces and facilitate subsequent expansion by adding other logistics provider interfaces.

[0079] Step B2: Define the general strategy for each logistics provider's interface. The general strategy rules include encryption rules, request header format setting rules, and return content encapsulation rules. Each general strategy rule is pre-configured with one or more strategy rule items (for example, encryption rules such as MD5 and SHA256 can be pre-configured). The strategy rule items correspond to the corresponding strategy rule items in the interface table.

[0080] Step B3: Create corresponding strategy implementation classes according to the specification requirements of each logistics provider's interface, which differ from the general strategy rules. The execution priority of the strategy implementation classes is higher than that of the general strategy rules. Map the general strategy and the strategy implementation classes to the factory pattern.

[0081] For example, when the encryption rules, request header formatting rules, return content encapsulation rules, or other rules required by a logistics provider's interface specification differ from the corresponding rules of the general strategy, corresponding strategy implementation classes need to be created for different rules. In this case, only the corresponding programming code needs to be added to the different rule parts, while the same rule parts can continue to use the strategy rule items to avoid additional programming, thereby significantly reducing the programming workload. The association relationship between each strategy rule and each strategy implementation class is stored in the virtual machine, enabling the system to accurately obtain callable and assemblable logistics provider data from the complex logistics provider data (data corresponding to the requirements of different types of logistics provider interface specifications) of different types, different levels, different formats, and different storage methods through the factory pattern, logistics provider identifier, logistics provider interface identifier, and strategy rule item identifier. This solves the problem of calling complex logistics provider data and reduces the difficulty of creating shared logical relationships between different logistics provider interfaces.

[0082] Step B4: Configure a common interface for unified invocation of interfaces from various logistics providers, including: Step B41: Create the first logic to obtain the target basic information group from the docking table based on the request task, logistics provider identifier and logistics provider interface identifier. The first logic also includes identifying the corresponding logistics provider identifier and logistics provider interface identifier according to the type of request task. Step B42: Create the second logic based on the strategy rule item identifier of the request task, logistics provider identifier, and target basic information group to obtain the corresponding target strategy rule item and target strategy implementation class from the factory pattern; Step B43: Assemble logistics provider data based on the obtained target basic information group, all target strategy rule items, and target strategy implementation class; Step B44: Create a third logic that automatically calls the corresponding logistics provider interface based on the assembly of logistics provider data.

[0083] Step B5: In response to the initial logistics data returned by the logistics provider interface, perform a reversal operation on the initial logistics data. That is, perform a uniform reversal operation on all data returned by the logistics provider interfaces to obtain target logistics data with a uniform format.

[0084] Step B6: After performing the reversal operation, clear the assembled logistics provider data. Configure a common interface for unified invocation of various logistics provider interfaces. This allows a temporary interface that can accurately connect to the logistics provider interface to be assembled in real time each time the system needs to connect to a specific logistics provider system to execute a request task. After the interface connection and request task are completed, the assembled logistics provider data is cleared, and the temporary interface is released for use by other request tasks, thereby solving the problem of interface allocation between the common interface and the logistics provider interface.

[0085] This interface configuration method based on public interfaces allows for batch configuration of interfaces, significantly reducing the amount of code required for the integration process, shortening configuration time, and improving the stability and scalability of the interfaces. In contrast, configuring an interface for a logistics provider system using the direct programming method typically takes about 2-3 days, while this batch integration method can reduce the configuration time for expanding a new logistics provider interface to about 20 minutes. The new method significantly improves the configuration efficiency of logistics provider interfaces and enhances the flexibility and compatibility of interface expansion and maintenance.

[0086] Furthermore, the applicant discovered that a very small number of logistics provider interfaces, even after passing null value validation (checking whether the interface request parameters in the request body and request header are empty, with null values ​​indicating an error) and interface configuration validation (verifying whether the configuration content of parameters such as the interface request address and request method is normal), and with all parameter values ​​correctly matched, still failed to return data from the logistics provider interfaces. After detailed investigation, it was found that the reason was that some users' browser environments cleared or disabled cookie data, causing the warehouse system to fail to successfully send cookie data to the logistics provider system, thus preventing the interface from returning data. Therefore, a special cookie request verification step was added to the integration system to improve the success rate of logistics data retrieval. Specifically, in step K4, a cookie request verification is performed on the logistics provider interfaces that need to send cookie data. This verification includes checking whether cookie data exists. If the cookie file exists, the cookie request verification is considered normal, and the integration request sending operation continues based on the normal cookie data; if the cookie file does not exist, the cookie request verification is considered abnormal, and the cookie data is regenerated (implemented through Java code), and the integration request sending operation continues based on the regenerated cookie data. Furthermore, when a cookie request verification fails, the error information can be logged, and an error report can be sent to the backend of the integrated system. Accordingly, logistics provider interfaces that require sending cookie data can be pre-marked in the integration table. When the system detects the corresponding cookie verification identifier, the cookie request verification operation will then be initiated. A cookie is simple text data stored on a client machine, used for session state management, personalization settings, and user behavior tracking, among other things.

[0087] refer to Figures 5-6 This application also provides a method for cost recovery based on discrepancies in shipments. In one embodiment of this application, the method is used in the product cost recovery module of an e-commerce ERP system, including steps R1-R32, as follows.

[0088] Step R1: Iterate through the receipt and shipment data of goods within the replenishment period to determine the receipt scenario to which the goods belong, and determine whether it is a discrepancy shipment based on the receipt scenario. The receipt scenario for a discrepancy shipment is any receipt scenario other than the normal receipt scenario. The replenishment period refers to the time range of the receipt data selected by the seller, including the current month and cross-month periods, and is related to the reconciliation cycle of the e-commerce profit report.

[0089] From the warehouse-side (referring to platforms providing logistics and storage services for shipments, such as logistics providers and third-party warehouses), select shipments with a signed status of "signed completed" within the replenishment period; index the corresponding shipping data for each shipment from the e-commerce ERP to determine the shipment volume and the volume of each item within the shipment; determine the signing scenario to which the shipment belongs based on the shipment volume and the signed volume. Determine whether the signed volume and the shipped volume of a shipment are equal from the shipment dimension; if they are equal, determine the shipment volume and signed volume of each item within the shipment; then, determine whether the shipment volume and signed volume of each item within the shipment are equal from the item dimension; if they are equal, the shipment is confirmed not to be a discrepancy shipment; if they are not equal, it is confirmed that there are mis-signed items within the shipment, and the shipment is a discrepancy shipment; if the shipment... If the quantities are not equal in any dimension, the shipment is considered a discrepancy shipment. The system checks if the shipped quantity exceeds the signed quantity. If it does, it confirms that the discrepancy shipment has under-signed items. The system locates the under-signed items based on the shipped and signed quantities of each item within the discrepancy shipment, and checks if the signed quantity of each item is 0. If it is 0, it confirms that the discrepancy shipment has missed signing items, and the missed signing items are located. If the quantities are less than the signed quantity, it confirms that the discrepancy shipment has over-signed items, and the over-signed items are located based on the shipped and signed quantities of each item within the discrepancy shipment.

[0090] Before calculating discrepancies in receipts, it is essential to ensure that the shipment's receipt status is "completed." If discrepancies exist in the initial transportation (the logistics process of transporting goods from the seller's warehouse to the e-commerce platform's warehouse), the cost of these discrepancies must be reimbursed. When the reimbursement period spans multiple months, the cumulative receipt discrepancies over several months are calculated and added back to the e-commerce profit report. The receipt status of each product code within each shipment is determined from the e-commerce platform's shipment interface, and the receipt quantity is calculated by summing the receipt details. Shipment details are retrieved from the shipping order based on the shipment number and product code, and the shipment quantity is calculated by summing the shipment details.

[0091] Step R2: If it is a discrepancy shipment, respond to the user operation on the discrepancy interface and determine the operation type of the user operation.

[0092] The operation types include replenishment operation, ignore operation, and view operation. The difference interface includes a product information area (used to display product data provided by the e-commerce ERP, including product images, product codes, shipment numbers, procurement costs, first-mile fees, etc.), a receipt difference area (used to display shipping data and receipt data at the product level, including shipping quantity, receipt quantity, receipt difference, cumulative replenishment cost, and remaining replenishment cost), and a user operation area (used to obtain user operations and execute corresponding response actions, including a replenishment operation area, an ignore operation area, and a view operation area. In the view operation area, the data records of each product after the cost replenishment logic is displayed according to the seller's view operation).

[0093] Step R31: When the operation type is a recovery operation, calculate the difference cost of the product corresponding to the recovery operation, and execute the cost recovery logic to recover the difference cost to the e-commerce profit report. The cost recovery logic includes calculating the target product cost of the product corresponding to the recovery operation based on the difference cost, locating the recovery cycle and profit statistics cycle of the product, and recovering the target product cost to the corresponding e-commerce profit report.

[0094] The system calculates the total difference cost for all items in a shipment that have undergone cost recovery logic, resulting in the cumulative recovery cost for the shipment (calculated by multiplying the cumulative quantity of recovered items by the cost of each individual item). The remaining recovery cost is calculated as: Difference Cost - Cumulative Recovery Cost. If the remaining recovery cost is not zero, the seller is prompted to perform another recovery operation. The system then calculates the sum of the purchase cost (from the shipping invoice and the allocated cost for the first leg of the journey) and the first leg cost (from the shipping invoice and the allocated first leg cost for the first leg of the journey) for the corresponding item, yielding the item's cost. The system also calculates the product of the receipt difference and the item cost, resulting in the difference cost. Finally, the system calculates the sum of the item's difference cost and the initial item cost (the item's cost when generating the e-commerce profit report), yielding the target item cost for the e-commerce profit report. Additionally, when receipt differences exist, a linked claim mechanism is established based on the receipt quantity details and the shipping invoice, requesting compensation for receipt differences from the e-commerce platform. Poll the platform compensation status of discrepancy shipments. When the platform compensation status is "compensated", obtain the platform compensation amount. Calculate the difference between the discrepancy cost and the platform compensation amount, adjust the discrepancy cost, and obtain the target product cost for the corresponding product in the compensation operation.

[0095] In one embodiment, when the replenishment period is one month, the shipment volume of product A within one month is 50 units, and the number of units signed for is 30 units. The difference in signed receipts is 50 - 30 = 20 units. The purchase cost of this batch of product A is 100 yuan, the initial shipping cost is 200 yuan, and the cost per unit of product A is (100 + 200) / 50 = 6 yuan. Therefore, the difference cost of product A is 20 * 6 = 120 yuan. After replenishing product A, the target product cost is 100 + 200 + 120 = 420 yuan after executing the cost replenishment logic. If the e-commerce platform claims 60 yuan, the difference cost is 120 - 60 = 60 yuan. After replenishing product A, the target product cost is 100 + 200 + 60 = 360 yuan.

[0096] Step R32: When the operation type is ignored, the initial product cost in the e-commerce profit report is used as the target product cost.

[0097] Confirm the receipt time of the goods corresponding to the ignore operation, determine the platform claim period for the goods based on the platform compensation time, and send a reminder message to the seller according to the platform claim period (to remind the seller to reimburse the cost of the goods). On the difference interface, the seller can trigger the synchronization of the difference cost to the e-commerce profit report individually or in batches, and ignore the difference cost individually or in batches, based on the difference in receipt of the goods.

[0098] In one embodiment, step R33 is further included: when the operation type is a view operation, a query for the recovered differential cost is triggered, and the cost recovery details interface is entered. The cost recovery details interface includes the product number, shipment number, cost recovery, recovery month, operation time, and operator. In the cost recovery details interface, the product data record format is: shipment number (uniquely identifying the shipment), product code (unique code for the product), and recovery time. Furthermore, when recovering costs by month, the delivery note, signed quantity details, and month-end in-transit details for the current month are determined. The delivery note is verified against the signed quantity details and month-end in-transit details to ensure cost recovery is compatible with in-transit scenarios.

[0099] In one embodiment, step R4 is further included: In the first-leg transportation, logistics data is obtained according to the tracking number of the shipment, and the logistics data is bound to the shipment number, with the tracking number + shipment number as the joint primary key; it is determined whether the receipt status of the shipment is completed within a preset time range; if so, a difference analysis operation is performed on the logistics data of the discrepancy shipment, the difference analysis operation includes parsing the logistics data, when the abnormal node is an e-commerce platform node (e.g., the logistics data shows that it has been delivered to the warehouse, but the warehousing record shows that the receipt quantity is less than the shipment quantity, and there is no record of logistics transportation damage / loss), then it is confirmed that the cause of the receipt difference is the e-commerce platform, and a claim is made to the e-commerce platform based on the discrepancy shipment; when the abnormal node is a transportation node (e.g., the logistics data shows that the shipment was delayed for too long during transportation, the weight was abnormally reduced in the transit stage, the shipment was damaged, there was no warehouse warehousing scan record, etc.), then it is confirmed that the cause of the receipt difference is the logistics provider, and a claim is made to the logistics provider based on the discrepancy shipment; if not, then it is confirmed that the abnormal node is a transportation node, and a shipment appeal is filed with the logistics provider based on the tracking number. The logistics nodes include pickup nodes, transportation nodes, and e-commerce platform nodes. By comparing with the standards of normal logistics nodes, abnormal nodes are located. In summary, by analyzing the reasons for discrepancies in signed receipts, the parties to the claims are identified, thus improving the efficiency of platform claims.

[0100] In one embodiment, calculating cost recovery based on the return completion time in a return scenario can lead to distortion of product costs across different periods. Therefore, when a return transaction spans multiple profit calculation periods, costs need to be split into corresponding periods. By determining the cost recovery period and calculating the amount, it is ensured that the cost attribution in the e-commerce profit report matches the actual time of the transaction. Specifically, when a product returns, the return receipt time t2 from the e-commerce platform's warehouse is obtained, and the order placement time t1 of the product's order is traced back. The difference between t2 and t1 is compared with the length of the standard profit calculation period to determine whether the order belongs to the product as a cross-period transaction. If t2-t1 > the length of the standard profit calculation period and t1 and t2 do not belong to the same profit calculation period, then the order to which the product belongs is confirmed as a cross-period transaction; otherwise, it is not. If it is not a cross-period transaction, the target profit calculation period of the order to which the product belongs is determined based on t1 and t2, and the target recovery amount is calculated based on the product cost. If it is a cross-period transaction, the target profit calculation period included between t1 and t2 is traversed, and the calculation is performed. The recovery weight of cross-period business in each profit statistics period (i.e., the proportion of the recovery amount to be borne in a single profit statistics period) is calculated as follows: Recovery weight = Effective duration of cross-period business within the profit statistics period / Total effective duration of cross-period business. The effective duration is the actual time covered by the cross-period business within a single profit statistics period, calculated as min(t2, end time of this profit statistics period) - max(t1, start time of this profit statistics period). The total effective duration is t2 - t1. Based on the recovery weight and product cost, the target recovery amount for the cross-period business in each target profit statistics period is calculated, and product cost is split according to the weight. Cost recovery is then performed based on the target profit statistics period and the target recovery amount. In summary, the target recovery amount for each profit statistics period is recovered to the corresponding e-commerce profit report (non-cross-period recovery is to a single profit statistics period, cross-period recovery is split into multiple profit statistics periods according to weight), ensuring that cost attribution matches the business occurrence time and effectively avoiding cost distortion. Additionally, min(a,b) is the smaller of the two values, and max(a,b) is the larger of the two values.

[0101] refer to Figures 7-8 This application also provides a method for rendering selection options based on millions of data points, used in the filtering and display module of an e-commerce ERP system. In one embodiment of this application, the method includes steps Q1-Q4, as follows.

[0102] Step Q1: Determine the visible area of ​​the dropdown selector, and calculate the rendering range of the visible area and the number of selections to be rendered based on the height of the selection and the text length.

[0103] Step Q2: Create standard nodes based on the number of renders, and fill each standard node with the display content of each initial selection.

[0104] After the dropdown panel of the dropdown selector expands, excluding scrollbars, filter bars, and other functional areas, the visible area is defined as the rectangular area used to display the options. The height of the visible area is calculated as: total height of the dropdown panel - height occupied by the functional areas within the dropdown panel. The width of the visible area is calculated as: max(width of the display container in the visible area + text length of the longest selection in the full dataset). The rendering range is determined based on the height and width of the visible area. The initial number of selections that the visible area can accommodate is calculated plus the number of preloaded selections. That is, the number of rendered selections is calculated as: height of the visible area / standard height of the selections (rounded down) + number of upper preloaded selections + number of lower preloaded selections. Data is extracted starting from the first data item in the full dataset based on the number of rendered selections. Create an independent display container within the dropdown panel to showcase the selection options, serving as the carrier of the visible area. This container is positioned below the filter bar and above the bottom buttons, completely isolated from other functional areas. Constraints on the display container include: overflow rules (vertical scrolling, horizontal scrolling disabled; when the number of options exceeds the visible area's capacity, only the vertical scroll bar is displayed, and horizontal scrolling is disabled); size locking (based on defined height / width); fixed position (the visible area's position within the dropdown panel is fixed; only the option content moves during scrolling, the visible area itself does not shift); and priority rules (the visible area must be fully displayed on the screen to prevent the panel from overflowing; if the bottom of the visible area exceeds the screen after expansion, the panel position automatically moves upwards). Additionally, the display container's hierarchy is above the panel background but below the functional areas.

[0105] In one embodiment, 300px (height of the visible area, where px is the height unit) ÷ 40px (standard height of the selection) = 7.5. Rounding down to 7 (the number of selections that can be fully displayed in the visible area), and adding 2 pre-loaded items above and below, the number of selections that need to be rendered in advance is 7 + 2 + 2 = 11. From the over one million data points, the first 11 items (ID: 1-11) are extracted and populated into standard nodes (i.e., a fixed DOM node pool). When the user opens the dropdown, they can directly see the first 7 data items (product, order, inventory).

[0106] Step Q3: In response to user actions within the visible area, adjust the displayed content of each standard node: Step Q31: In response to the first user operation in the visible area, perform an update operation on the standard nodes. The first user operation is a scrolling operation. The update operation is to determine the update selection based on the scrolling direction and scrolling distance, match each update selection with each standard node, and update the display content of each standard node.

[0107] The relationships between each selection option are determined, including hierarchical relationships, business relationships, and dependency relationships. Hierarchical relationships are those between categories, brands, and specifications; business relationships are those between orders, buyers, and warehouses; and dependency relationships are those between products and accessories. When upper-level data is selected, lower-level data is filtered based on these relationships, and the dropdown selector's option list is updated. The dropdown selector's options are displayed in a collapsed manner according to their relationships. These relationships are bound to virtual nodes in a hash map and queried during rendering to avoid traversing the entire dataset. Specifically, for establishing hierarchical relationships, firstly, the mapping relationship between parent data identifiers and child data lists is defined, and the hierarchical level is defined. Parent data identifier and hierarchical level fields are added to the virtual nodes of each option, and the hierarchical dictionary is cached. For establishing dependency relationships, firstly, dependency relationships are defined according to dependency types (recommended dependency, mutually exclusive dependency, required dependency), and a mapping relationship between master data identifiers and dependency data identifier lists is established. Dependency type and dependency data identifier list fields are added to the virtual nodes of each option, and the dependency relationships are cached. For establishing business relationships, the association fields for each option are determined, association fields are added to the virtual nodes of each option, and the business relationships are cached.

[0108] Based on the association information stored in the virtual nodes, automated processing of associated data is achieved. The hierarchical associations are category-brand-specification hierarchical relationships; the business associations are order-customer-warehouse business object associations; the dependency associations are product-accessory dependency relationships; and the hierarchical dictionary maps upper-level data identifiers to lower-level data lists. When upper-level data is selected, lower-level data is filtered based on the hierarchical dictionary, and the dropdown selector's option list is updated. The dropdown selector's options are then displayed in a collapsed manner according to the hierarchy.

[0109] Step Q32: In response to a second user operation in the visible area, perform a standard node mapping operation. The second user operation includes a click operation. The mapping operation updates the selection status of the target selection item corresponding to the second user operation, integrates the selection status and the business information of the target selection item to obtain the virtual node of the target selection item, obtains the identification information of the target selection item, and establishes a mapping relationship between the identification information and the virtual node. The identification information can uniquely identify each selection item. The business information includes the inventory status of the product, the order status of the order, and the store identifier to which the selection item belongs.

[0110] Based on the first user operation, the scrolling direction and scrolling distance are determined, and a new visible data index range is calculated in combination with the scrolling offset height in the virtual node; a new index is assigned to each standard node, and the display content and business status of the standard nodes are updated.

[0111] The identification information includes the product code and order number. The virtual node includes the location information of the selection item in the full data, the selection status of the selection item, and the offset distance of the selection item from the top of the scroll container. The offset distance is the vertical position coordinate of the selection item, which is the basis for mapping data to pixels and represents the position of the data rendered in the standard node, i.e., the selection item, among all rendered and unrendered data. A key-value mapping table is established using the identification information as the key and the virtual node as the value. The unique identifier is the product ID, SKU, order number, or a composite ID. The virtual node at least contains the original index of the data in the full data, the scroll offset height, the selection status, and a list of associated data identifiers. The virtual node stores business dimension information, including the product's inventory status, the order's order status, and the store identifier to which the data belongs. The hash mapping table supports composite key storage, where the composite key is a combination of the store identifier and the product ID, used for data isolation in multi-store scenarios. The system queries data from corresponding virtual nodes based on mapping relationships. When the dropdown selector loads data, it synchronously retrieves business-related fields and stores them in the virtual nodes. When target data is selected, the system queries the business-related fields through a hash mapping table, automatically displays them in the option labels, and populates the associated form fields. These business-related fields include the customer name and warehouse name corresponding to the order. When selecting target data in batches, the system aggregates and displays the commonalities and differences of the business-related fields. It also supports filtering selected data based on business-related fields, enabling batch removal of data with specified associated attributes.

[0112] The dropdown selector includes: a scroll monitoring module, used to monitor scrolling operations of the dropdown panel, calculate a new visible data index range, assign new indexes to standard nodes, query data through a hash mapping table, and update the content of the standard nodes; a lazy loading container component, used to respond to pop-ups when user operations are received; a hash mapping construction module, used to establish a key-value pair mapping relationship using the unique identifier of business data as the key and virtual nodes containing data location information, business status information, and association information as the value; a standard node management module, used to create a fixed number of standard node pools, the number of which is the sum of the number of options that can be displayed in the visible area and the number of pre-loaded options above and below; an association linkage module, used to automate the hierarchical association filtering, business association filling, and dependency association recommendation and restriction based on the association information in the virtual nodes; a virtual node construction module, used to encapsulate the original data into virtual nodes; and a rendering module, used to render and display the standard nodes filled with data.

[0113] When the first user's scroll distance is at the edge, upon reaching the top of the full data, the first standard node in the standard node pool is displayed as the first selection in the full data; upon reaching the bottom of the full data, the last standard node in the standard node pool is displayed as the last selection in the full data. For example, if the user scrolls to the top or bottom of the full data, upon reaching the top, the first few standard nodes in the standard node pool are assigned the first index; upon reaching the bottom, the last few standard nodes in the standard node pool are assigned the last index, ensuring that no data is missing; if the data corresponding to the new index does not exist, empty data processing is performed, and invalid content is not updated.

[0114] Step Q4: Render each standard node and display the rendered standard nodes in the visible area.

[0115] Extract all information to be displayed (including business information and selection status) from virtual nodes and integrate it into a content structure that conforms to e-commerce ERP specifications. Ensure that the display structure of all standard nodes is consistent. For each standard node in the fixed standard node pool, perform a clear and fill operation (only operate on the content, do not add / delete nodes), and keep the position of the standard node unchanged. Finally, calibrate the position of the filled standard nodes. Specifically, calculate the absolute position of each standard node in the drop-down panel based on the scroll offset height in the virtual nodes, determine the layout position of each standard node. For example, if the scroll offset height of the 5th product is 160px, the absolute position of the corresponding standard node is set to 160px. Then, anchor the visible area range and adjust the absolute position of the standard nodes. On the browser side, perform partial redrawing of standard nodes with updated content.

[0116] The above description is merely a preferred embodiment of this application and does not limit the patent scope of this application. All equivalent modifications made based on the inventive concept of this application and the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the patent protection scope of this application.

Claims

1. A method of brand analysis based on traffic positioning, characterized by, A brand analysis module for e-commerce ERP, the method comprising: Step A1: obtaining total traffic data of goods under the brand to be analyzed and search words on the e-commerce platform, the total traffic data including goods traffic data in the whole process node of goods ordering and search word traffic data of goods under each search word; Step A2: calculating the traffic indicators corresponding to the goods and search words based on the total traffic data, and positioning the traffic anomalies of the goods and search words based on each traffic indicator and the abnormality determination rules corresponding to the goods and search words: The traffic indicators of the goods include the positioning type, life cycle, exposure amount, and conversion rate of the goods, and the abnormality determination rules of the goods include calculating the current values of the exposure amount and conversion rate based on the goods traffic data, determining the traffic anomalies of the goods based on the comparison results of the current values of the exposure amount and conversion rate and the standard threshold values corresponding to the positioning type and life cycle of the goods; The traffic indicators of the search words include the correlation strength and traffic score, and the abnormality determination rules of the search words include calculating the correlation strength of each search word and the goods based on the search word traffic data, and determining the traffic anomalies of the search words based on the traffic scores of each strongly correlated search word when the correlation strength is strong; Step A3: based on the traffic anomaly determination results of the goods and search words, performing operation anomaly analysis on the brand.

2. The method of claim 1, wherein, Step A2 further comprises: obtaining the exposure amount of each good and determining whether the numerical value and change of the exposure amount are within the abnormal range; if yes, confirming that the exposure of the goods is abnormal; constructing a conversion funnel of the whole process node of goods ordering based on the goods traffic data, calculating the conversion rate of the goods based on the conversion funnel, and confirming that the conversion of the goods is abnormal when the conversion rate is less than the corresponding standard threshold value, wherein the whole process node is the whole process node of the goods from exposure to click, then to add to cart, and finally to order, the positioning type is the attribute label of each good in the brand, including lead-in, profit, image, and long tail, the life cycle is the operation cycle of the goods from listing to delisting, including import period, growth period, mature period, and decline period, and the conversion rate is the ratio of exposure, click, add to cart, and order, including click rate, click to add to cart rate, add to cart to order rate, and overall conversion rate; when the goods have exposure anomalies or / and conversion anomalies, confirming that the goods have traffic anomalies.

3. The method of claim 2, wherein, Step A2 further comprises: performing delivery time efficiency layering processing on the goods traffic data based on the delivery type of the goods to obtain the goods traffic data under each delivery type, wherein the delivery type includes same-day delivery, next-day delivery, and standard delivery, and the delivery time efficiency layering processing includes dividing the goods traffic data into three parts based on the delivery type of the goods.

4. The method of claim 1, wherein, Step A2 further comprises: calculating the correlation strength of the goods and each search word, wherein the calculation dimensions of the correlation strength include the semantic matching degree of the similarity between the search word and the keyword of the goods, the conversion relevance of the conversion ability of the search word to the goods ordering, and the intention matching degree of the matching degree between the search word and the category to which the goods belong; determining whether the correlation strength is strong correlation; If yes, a flow score of each strongly associated search word is calculated, and a search word flow anomaly is confirmed when the flow score is less than a score threshold, wherein the flow score refers to the degree of association between the flow change of the search word and the brand and the degree of influence on the brand.

5. The method of claim 4, wherein, Step A2 further includes: calculating a semantic matching degree of each search word with each field of the commodity introduction data; disassembling the intent elements of each search word and corresponding to the category elements of each commodity, and calculating an intent matching degree of each search word according to the weighted values of each category element; calculating the conversion rate, abnormal conversion proportion, and order placement path length of each commodity under each search word according to search word-commodity data in the search word flow data, and calculating conversion relevance according to the corresponding conversion weight, wherein the search word-commodity data refers to the data of a single commodity under a search word.

6. The method of claim 1, wherein, Step A1 further includes: generating a visual chart according to the total flow data, wherein the visual chart includes a time index trend chart of commodity order placement, a conversion funnel chart of the whole process nodes of commodity order placement, a search word table showing search words and product shares, and a conversion proportion pie chart showing the contribution proportion of each search word to the total order quantity.

7. The method of claim 1, wherein, Step A3 further includes: obtaining brand flow data of a brand to be analyzed, calculating the flow performance of the brand to be analyzed, wherein the brand flow data includes driving flow data brought by the brand to the commodity under the brand and loss flow data reduced by the influence of competitive products, and the flow performance is the product of the current values of the driving flow data and the loss flow data and the corresponding flow weights; performing flow anomaly judgment on the brand based on the flow performance of the brand to be analyzed, and performing operation anomaly analysis on the brand based on the flow anomaly judgment results of the commodity, the brand, and the search word.

8. The method of claim 7, wherein, Step A3 further includes: performing first-level judgment on the flow situation of the brand, wherein the first-level judgment includes: a first judgment logic that when the brand flow anomaly is confirmed according to the brand flow performance, the second-level judgment is entered; or a second judgment logic that when the brand slight anomaly is confirmed according to the brand flow performance, and in the commodity dimension, the number proportion of the commodity with flow anomaly under the brand slight anomaly is greater than 1 / 3 of all commodities under the brand, or in the search word dimension, the search word flow score confirms that the search word has flow anomaly, the second-level judgment is entered; performing second-level judgment on the flow situation of the commodity and the search word, wherein the second-level judgment includes: when the number proportion of the commodity with flow anomaly under the brand with flow anomaly is greater than 1 / 5 of all commodities under the brand and the search word flow score confirms that the search word has flow anomaly after the first judgment logic is executed, the brand operation anomaly is confirmed; or when the sum of the number proportion of the commodity with flow anomaly and the commodity with slight flow anomaly under the brand with flow anomaly is greater than half of all commodities under the brand after the first judgment logic is executed, the brand operation anomaly is confirmed; or when the competitive product influence degree is greater than or equal to 0.8 and the brand driving degree is less than or equal to 0.2 after the first judgment logic is executed, the brand operation anomaly is confirmed. After the second judgment logic is executed, when the number ratio of the goods with traffic anomaly under the brand with slight anomaly is greater than 2 / 5 of all the goods under the brand and the number of the search words with traffic anomaly is greater than half of all the search words, it is confirmed that the brand operation is abnormal.

9. The method of claim 1, wherein, The step A2 further comprises: The score dimensions of the traffic score include a traffic size dimension, a conversion quality dimension, a traffic proportion dimension, and a traffic stability dimension, the traffic size dimension refers to the size of the traffic pool where the search word is located, the conversion quality dimension refers to the order conversion capability of the search word, the traffic proportion dimension refers to the traffic proportion of the brand in the traffic pool of the search word, and the traffic stability dimension refers to the capability of the search word to continuously bring traffic. The score values of the search word in the traffic size dimension, the conversion quality dimension, the traffic proportion dimension, and the traffic stability dimension are calculated, the score weights of the respective score dimensions are defined, and the product sum of the respective score values and the corresponding score weights is calculated to obtain the traffic score of the search word.

10. A traffic-based brand analysis system, characterized by, The system is an e-commerce ERP system, and the system executes the operation instructions included in the brand analysis method based on traffic positioning in any one of claims 1-9.

Images