A GEO-based article AI search exposure effect evaluation method, server, product and medium

Abstract

A GEO-based article AI search exposure effect evaluation method, server, product and medium, relating to the field of search optimization, the method comprises: performing semantic analysis on the title and body of the article to be evaluated, taking the title as the main part and the body as the auxiliary part, and extracting core promotion entities and associated attribute descriptions; based on the extraction results, constructing multiple query questions according to user information acquisition scenarios; sending the query questions to multiple generative AI dialogue platforms for network search, obtaining the answer content and extracting the reference source address; matching and comparing the article original address with the reference source address, counting the number of occurrences of the original address in the answers of each AI platform to obtain the article hit frequency; obtaining the weight data of the website where the article is located, and calculating the comprehensive exposure score according to the hit frequency and the weight data. By implementing the present application, the exposure frequency of the article in the generative AI platform can be detected and quantified.

Description

Technical Field

[0001] This application relates to the field of search optimization, and in particular to a method, server, product, and medium for evaluating the exposure effect of article AI search based on GEO. Background Technology

[0002] GEO (Generative Engine Optimization) refers to the technological approach of optimizing content for generative AI search engines to improve the visibility and citation probability of content in AI-generated answers. With the widespread adoption of generative AI dialogue platforms like ChatGPT, users are shifting their information acquisition methods from traditional web browsing to AI question-and-answer. Users obtain comprehensive answers by asking AI questions, and whether an article's content can be retrieved and cited by AI directly impacts its dissemination. Therefore, it is necessary to evaluate the promotional effect of articles in an AI search environment.

[0003] In related technologies, article promotion effect evaluation technology collects traffic indicators such as page views, clicks, and reposts provided by the publishing platform, and calculates a comprehensive score by weighting these data, thereby quantifying the dissemination effect of the article.

[0004] The aforementioned technical statistics are behavioral data from users directly accessing article pages. When users obtain information through an AI platform using a question-and-answer format, although the article content is retrieved and cited by the AI ​​and reaches the user through the AI ​​answer, the user does not directly access the original text. Therefore, the publishing platform cannot capture this traffic, resulting in the evaluation results failing to reflect the exposure effect achieved by the article through the AI ​​platform. Summary of the Invention

[0005] This application provides a method, server, product, and medium for evaluating the exposure effect of GEO-based article AI search, which is used to detect and quantify the exposure frequency of articles in generative AI platforms.

[0006] Firstly, this application provides a method for evaluating the exposure effect of article AI search based on GEO, applied to a server. The method includes: acquiring the title text and body text of the article to be evaluated; performing semantic parsing on the title text as the primary extraction object and the body text as the auxiliary extraction object to extract core promotion entities and related attribute descriptions; constructing multiple query questions based on the core promotion entities and related attribute descriptions, according to user information acquisition scenarios; sending the multiple query questions to multiple generative AI dialogue platforms for online search, obtaining the answer content returned from the generative AI dialogue platforms, and extracting the citation source address from the answer content; matching and comparing the original address of the article to be evaluated with the citation source address, counting the number of times the original address appears in the answer content returned by the multiple generative AI dialogue platforms, and obtaining the article hit frequency; acquiring the weight data of the website where the article to be evaluated is located, and calculating a comprehensive exposure score based on the article hit frequency and weight data.

[0007] In the above embodiments, core promotional entities and associated attributes are extracted through semantic parsing, and query questions that conform to user scenarios are constructed and sent to multiple generative AI platforms for searching. This method matches the original URL of the article with the source URLs cited in the returned answers, counts the hit frequency, and calculates a comprehensive exposure score by combining it with website weight data. This compensates for the deficiency of traditional traffic statistics in capturing article exposure in AI question-and-answer scenarios, and provides content creators with a basis for evaluating the promotional effect in the AI ​​era.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the step of constructing multiple query questions based on core promotion entities and associated attribute descriptions according to user information acquisition scenarios specifically includes: concatenating and combining the core promotion entities with the attribute words in the associated attribute descriptions to generate multiple query seed words; calling the query association interface of the target search engine with the multiple query seed words respectively, and extracting the related search terms displayed in the search results page of the target search engine, and aggregating them into a candidate query set; classifying each candidate query in the candidate query set according to the intent dimension based on a preset user intent dimension system, and counting the number of candidate queries under each intent dimension to evaluate query coverage; determining the intent dimensions with a candidate query number lower than a preset coverage threshold as intent dimensions to be supplemented, filling the entity slots of the preset query template with the core promotion entities based on the preset query template corresponding to the intent dimensions to be supplemented to generate supplementary query statements, and adding the supplementary query statements to the candidate query set to obtain multiple query questions.

[0009] In the above embodiments, seed keywords for queries are generated by concatenating core promotional entities and attribute words, and a candidate query set is constructed by calling the search engine's association interface to obtain relevant search terms. Based on a user intent dimension system, the queries are categorized and their coverage is evaluated. For intent dimensions with insufficient coverage, query statements are supplemented using preset templates to ensure that the test queries cover users' real information acquisition needs, thereby improving the representativeness and comprehensiveness of the exposure effect evaluation.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the step of classifying each candidate query in the candidate query set according to the preset user intent dimension system specifically includes: determining the category attribute to which the core promotion entity belongs; querying the intent dimension combinations associated with the category attribute from the preset intent dimension library as a coverage verification list, wherein different category attributes in the intent dimension library correspond to different intent dimension combinations, and each intent dimension is configured with a corresponding set of feature words; detecting whether each candidate query in the candidate query set contains the feature words corresponding to each intent dimension in the coverage verification list, and classifying the candidate queries containing the feature words into the corresponding intent dimension; traversing all intent dimensions in the coverage verification list, and determining the intent dimensions whose number of classified candidate queries is zero or lower than the preset coverage threshold as intent dimensions to be supplemented.

[0011] In the above embodiments, the corresponding intent dimension combination is queried from a preset intent dimension library based on the category attributes of the core promotion entity. Candidate queries are categorized by detecting whether they contain feature words of each intent dimension, and intent dimensions with insufficient candidate query quantity are identified as dimensions to be supplemented. This solution employs a targeted intent dimension system for different categories, avoiding evaluation bias caused by a uniform standard and improving the accuracy of query construction.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the step of matching and comparing the original address of the article to be evaluated with the source address of the reference, and counting the number of times the original address appears in the response content returned by multiple generative AI dialogue platforms to obtain the article hit frequency, specifically includes: performing URL normalization processing on the original address of the article to be evaluated, removing the differences in dynamic query parameters and protocol identifiers in the original address to obtain a normalized original address; performing step-by-step redirection tracking on each source address to obtain the final landing address reached by each source address after redirection; performing URL normalization processing on each final landing address, removing the differences in dynamic query parameters and protocol identifiers in each final landing address to obtain each normalized reference address; performing string matching between the normalized original address and each normalized reference address, counting the number of times the successfully matched normalized reference address appears in the response content returned by multiple generative AI dialogue platforms, and using the number of appearances as the article hit frequency.

[0013] In the above embodiments, the original address and the referencing source address are URL normalized to remove dynamic parameters and protocol differences. A step-by-step redirection is performed on the referencing source address to obtain the final landing address, and the normalized address is then matched. This solution resolves the matching failure problem caused by redirection and parameter changes, accurately identifies references to the article to be evaluated in the AI ​​platform's responses, and avoids statistical bias caused by differences in address formats.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the step of obtaining the weight data of the website where the article to be evaluated is located, and calculating the comprehensive exposure score based on the article hit frequency and the weight data, specifically includes: obtaining the site authority score of the website where the article to be evaluated is located and the average hit frequency of historically evaluated articles on the website where the article to be evaluated is located across multiple generative AI dialogue platforms; using the site authority score and the average hit frequency as weight data; calculating the ratio of the article hit frequency to the average hit frequency to obtain a relative exposure intensity coefficient, which is used to characterize the difference in exposure capability of the article to be evaluated relative to historically evaluated articles on the website where the article to be evaluated is located; and calculating the comprehensive exposure score based on the relative exposure intensity coefficient and the site authority score.

[0015] In the above embodiments, the website's authority rating and the average hit frequency of historical articles are obtained as weighting data. The relative exposure intensity coefficient is obtained by calculating the ratio of article hit frequency to average hit frequency, and this is combined with the website's authority rating to calculate a comprehensive exposure score. This scheme considers both the article's own exposure performance and the website's overall authority, enabling horizontal comparisons between websites of different authority levels and providing more valuable evaluation indicators.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after obtaining the weight data of the website where the article to be evaluated is located and calculating the comprehensive exposure score based on the article hit frequency and weight data, the method further includes: identifying addresses in the source address that fail to match the original address of the article to be evaluated as competitive reference addresses; performing domain aggregation and page deduplication on the competitive reference addresses to obtain a set of competitive articles; counting the number of times each competitive article appears in the answer content in the set of competitive articles to obtain the competitive hit frequency of each competitive article; sorting the article hit frequency and each competitive hit frequency in descending order to generate a competitive exposure ranking; and outputting the competitive exposure ranking and the comprehensive exposure score as an exposure effect evaluation report.

[0017] In the above embodiments, the source addresses of failed matches are identified as competing reference addresses. These addresses are then subjected to domain aggregation and page deduplication to obtain a set of competing articles. The hit frequency of each competing article is counted and sorted in descending order with the hit frequency of the articles to be evaluated, generating a competitive exposure ranking and outputting an evaluation report. This solution not only evaluates the exposure effect of the articles themselves but also identifies competing content under the same query scenario, providing content creators with a basis for competitive landscape analysis.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, the step of performing domain name aggregation and page deduplication on the competing reference addresses to obtain a set of competing articles specifically includes: performing hierarchical redirection tracing and URL normalization on each competing reference address to obtain each normalized competing landing address; aggregating and grouping each normalized competing landing address according to the domain name dimension, merging and deduplicating addresses with the same path identifier under the same domain name, and using each address retained after deduplication as an independent competing article, and summarizing them to obtain a set of competing articles.

[0019] In the above embodiments, hierarchical redirection tracing and URL normalization are performed on competing reference addresses. Aggregation and grouping are performed by domain name, and addresses with the same path under the same domain are merged and deduplicated. The deduplicated addresses are then aggregated as independent competing articles to obtain a set of competing articles. This scheme accurately identifies different competing articles, avoids statistical biases caused by address variations or duplicate references, and ensures the accuracy of the competitive analysis results.

[0020] In a second aspect, embodiments of this application provide a server comprising: one or more processors and a memory; the memory is coupled to the one or more processors and is used to store computer program code, the computer program code including computer instructions, wherein the one or more processors invoke the computer instructions to cause the server to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a server, cause the server to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a server, cause the server to execute the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the server provided in the second aspect, the computer storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. By extracting core promotional entities to construct query questions and sending them to multiple generative AI platforms, matching the original article address with the cited source address to count the hit frequency, and combining this with weighted data to calculate a comprehensive exposure score, the traditional traffic statistics method effectively solves the technical problem that it cannot capture when users obtain information through AI platforms, resulting in the evaluation results failing to reflect the exposure effect of the article through the AI ​​platform. This allows for the quantification of the exposure frequency of articles on generative AI platforms and provides a basis for evaluating the content promotion effect.

[0026] 2. By using the method of concatenating core promotional entities and attribute words to generate seed keywords for queries, calling the search engine association interface to construct a candidate query set, evaluating coverage based on the user intent dimension system, and generating supplementary query statements for insufficiently covered intent dimensions through preset templates, this effectively solves the technical problem that test queries cannot cover users' real information acquisition needs due to a single query sample or failure to consider the distribution of user intent when constructing test queries, thus making the evaluation results unrepresentative. In this way, it realizes the construction of a query question set that comprehensively covers user information acquisition scenarios and improves the accuracy of exposure effect evaluation.

[0027] 3. By performing URL normalization on the original address, and performing step-by-step redirection tracking to obtain the final landing address and then performing URL normalization on the referenced source address, the system effectively solves the technical problems of matching failure and hit frequency statistical deviation caused by the inconsistency between the referenced source address and the original address due to redirection or differences in additional tracking parameters and protocol identifiers. This enables accurate identification of references to the article to be evaluated in the AI ​​platform's response content and provides reliable hit frequency statistical results. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating a method for evaluating the exposure effect of GEO-based article AI search in this application.

[0029] Figure 2 This is another flowchart illustrating the GEO-based article AI search exposure effect evaluation method in this application embodiment;

[0030] Figure 3 This is a schematic diagram of the physical device structure of a server in an embodiment of this application. Detailed Implementation

[0031] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0032] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0033] For ease of understanding, the method provided in this implementation is described in process below. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating a method for evaluating the exposure effect of GEO-based article AI search in this application.

[0034] S101. Obtain the title text and body text of the article to be evaluated. Use the title text as the main extraction object and the body text as the auxiliary extraction object for semantic parsing to extract the core promotion entity and related attribute description.

[0035] In this context, the title text refers to the article's title, while the body text refers to the main content. Semantic parsing refers to the process of analyzing text using natural language processing techniques to identify entities, attributes, and their semantic relationships within the text. The core promotional entity refers to the main object extracted from the article that best represents the article's promotional goals, such as a product name or brand name. Related attribute descriptions refer to descriptive information related to the core promotional entity, such as the product's features or application scenarios.

[0036] Specifically, the server obtains the complete URL of the article to be evaluated, accesses the address using web crawling technology, parses the webpage structure, and extracts the text data corresponding to the title tags and body content tags from the HTML document. The server then uses a natural language processing model to perform deep analysis on the title text, identifying named entities, verb phrases, and noun phrases in the title, and determining the entities with the highest frequency or semantic weight as core promotion entities. For the body text, the server extracts paragraph content related to the title theme, identifies adjectives, adverbs, and prepositional phrases modifying the core promotion entities through dependency parsing, and summarizes these modifying components into related attribute descriptions. The server uses the TF-IDF algorithm to calculate word importance, and combines this with part-of-speech tagging results to filter out attribute words with actual semantic value, while filtering out stop words and function words.

[0037] In some embodiments, semantic parsing and entity extraction can be implemented in multiple ways: Optionally, the server employs a rule-based approach, pre-defining an entity recognition rule base and an attribute extraction pattern base, matching the title text with patterns in the rule base, and extracting core promotional entities and associated attribute descriptions from the matching locations; Optionally, the server employs a deep learning-based named entity recognition model, inputting the title text and body text into a pre-trained BERT model, obtaining the context vector representation of each word through the model's encoding layer, inputting the vectors into the entity classification layer to identify entity boundaries and entity types, and selecting product or brand entities as core promotional entities from the recognition results, while simultaneously extracting modifiers around the entities as associated attribute descriptions. It is understood that other methods can also be used to implement semantic parsing and entity extraction, which are not limited here.

[0038] S102. Based on the core promotion entity and associated attribute descriptions, construct multiple query questions according to the user information acquisition scenario.

[0039] Among them, user information acquisition scenarios refer to various query situations that users may raise when using the generative AI dialogue platform, including evaluation queries, recommendation queries, comparison queries, and question-and-answer queries. Query questions refer to natural language questions constructed to simulate the user's real search intent, containing core promoted entities and related attributes, used to initiate retrieval requests to the generative AI dialogue platform.

[0040] Specifically, the server constructs a set of query questions based on the extracted core promotional entities and associated attribute descriptions, according to a pre-defined user information acquisition scenario classification system. The server identifies the category attributes of the core promotional entities and retrieves the corresponding query templates from the scenario template library based on these attributes. The query templates contain fixed sentence structures and variable entity slots. The server fills the entity slots with the core promotional entities and the attribute slots with the key attribute words from the associated attribute descriptions, generating query questions that conform to natural language expression habits. For evaluation scenarios, it generates query questions like "How is product X?"; for recommendation scenarios, it generates query questions like "Recommend a useful product X?"; and for comparison scenarios, it generates query questions like "Which is better, product X or product Y?". The server performs deduplication on the generated query questions, filtering out questions with semantic repetition or similar expressions.

[0041] In some embodiments, query questions can be constructed in several ways: Optionally, the server uses a template-based approach, pre-defining query templates corresponding to different information retrieval scenarios. The templates contain placeholders for entity and attribute slots. The server sequentially fills the corresponding slots with terms from the core promoted entity and associated attribute descriptions, generating multiple query questions through permutations and combinations. Optionally, the server uses a generative model-based approach, using the core promoted entity, associated attribute descriptions, and scenario type as input prompts. It then calls a large language model to generate multiple query questions that fit the scenario. The server performs grammar checks and relevance filtering on the generated questions, retaining only those highly relevant to the core promoted entity. It is understood that other methods can also be used to construct query questions, and this is not limited here.

[0042] S103. Send multiple query questions to multiple generative AI dialogue platforms for online search, obtain the answer content returned by the generative AI dialogue platform, and extract the source address from the answer content.

[0043] In this context, a generative AI dialogue platform refers to an AI-powered dialogue system with natural language understanding and generation capabilities. It can receive user queries, retrieve relevant information through online searches, and then generate responses. Online search refers to the process by which the generative AI dialogue platform uses search engines or accesses internet resources to retrieve web page content and data related to the query. The source URL refers to the web page URL that the generative AI dialogue platform marks in its responses as the source of the information.

[0044] Specifically, the server sends multiple constructed query questions to several pre-configured generative AI dialogue platforms via API interfaces or automated scripts. The server creates an independent session request for each query question, setting an indicator to enable online search functionality in the request parameters. The server submits the query questions to the dialogue interfaces of each platform via the HTTP protocol and receives response data in JSON or HTML format from the platforms. The server parses the structure of the response data, identifying citation markers or links in the response text. These markers typically appear in the response content as superscript numbers, square bracket numbers, or hyperlinks. The server extracts the URLs corresponding to the citation markers and stores these addresses as a list of citation source addresses. The server uses regular expressions or HTML parsing libraries for unified data extraction processing to ensure accurate identification of citation source addresses from various formats. The server records the association between the response content and citation source addresses for each query question.

[0045] It should be noted that when processing the same query question, the generative AI dialogue platform may receive different answers and source URLs at different times due to the randomness of its internal model generation and the real-time changes in online search results. To improve the stability and reproducibility of the evaluation results, the server executes multiple independent queries to the same generative AI dialogue platform for each query question within a preset time window, creating a new session for each query to avoid the influence of contextual associations. The length of the preset time window is set according to the evaluation accuracy requirements, for example, 24 hours. The server records the answer content and source URL returned for each query and summarizes the results of multiple queries for the same query question. When calculating the article hit frequency, the server calculates the proportion of times the same query question hits the article to be evaluated in multiple queries out of the total number of queries for that query question, and uses this proportion as the hit probability of that query question. The server sums or averages the hit probabilities of all queries to obtain the article hit frequency after multiple sampling corrections. By using multiple sampling to obtain statistical measures, the impact of random fluctuations in single query results on the final evaluation results is reduced, making the statistical results of article hit frequency more stable and reliable. In actual deployment, the number of queries can be configured based on the assessed cost and accuracy requirements, for example, executing 3 to 5 independent queries for each query question.

[0046] In some embodiments, sending query questions to a generative AI dialogue platform and extracting reference source addresses can be achieved in several ways: Optionally, the server sends query questions one by one synchronously, waiting for the platform to return a complete answer after each query, parsing the answer to extract the reference source address, and then sending the next query question; Optionally, the server sends query questions in batches asynchronously and concurrently, initiating multiple session requests to multiple generative AI dialogue platforms simultaneously, using multithreading or coroutine technology to achieve concurrent processing, and triggering a callback function to parse data and extract reference source addresses when a platform returns an answer. It is understood that other methods can also be used to send query questions and extract reference source addresses, and these are not limited here.

[0047] S104. Match and compare the original URL of the article to be evaluated with the source URL, and count the number of times the original URL appears in the response content returned by multiple generative AI dialogue platforms to obtain the article hit frequency.

[0048] Here, the original address refers to the actual URL of the article to be evaluated on the Internet. Matching and comparison refers to the process of comparing two URLs to determine whether they point to the same webpage resource. Article hit frequency indicates the number of times the article to be evaluated is cited by the generative AI dialogue platform.

[0049] Specifically, the server preprocesses the original URL of the article to be evaluated, removing tracking parameters, session identifiers, and anchor tags from the URL, standardizing the protocol identifier to HTTPS format, and normalizing the www prefix in the domain name to obtain a normalized original URL. The server iterates through all source URLs collected from various generative AI dialogue platforms, performing the same normalization process on each source URL. The server performs a string-by-string match between the normalized original URL and each normalized source URL; a successful match is determined when the domain name and path portions of the two URLs are completely identical. For source URLs that do not directly match, the server performs HTTP request tracing to obtain the final landing address after redirection, normalizes the final landing address, and matches it again against the original URL. The server counts the number of times all successfully matched source URLs appear in the response content and sums the results to obtain the article hit frequency.

[0050] In some embodiments, address matching and hit frequency statistics can be implemented in multiple ways: Optionally, the server uses an exact matching method, directly comparing the normalized original address with the referencing source address; a match is considered successful only when the two addresses are completely identical. Optionally, the server uses a fuzzy matching method, calculating the similarity between the original address and the referencing source address, extracting the domain name and path backbone of the two addresses; a match is considered successful when the domain name is completely identical and the path similarity exceeds a preset threshold. It is understood that other methods can also be used to implement address matching and comparison, and these are not limited here.

[0051] In some embodiments, this step specifically includes:

[0052] The original URL of the article to be evaluated is URL normalized to remove dynamic query parameters and protocol identifier differences in the original URL, resulting in a normalized original URL.

[0053] URL normalization refers to the standardization of URL addresses, eliminating differences in address representation and converting different URLs pointing to the same resource into a unified standard format. Dynamic query parameters are key-value pairs appended to the end of the URL, starting with a question mark, used to convey session information or tracking data, such as `sessionid` and `utm_source`. Protocol identifier differences refer to the different use of HTTP or HTTPS protocols in the URL; these two protocols are functionally equivalent but have different string representations. A normalized raw URL is the standard URL address obtained after normalizing the original URL of the article being evaluated.

[0054] The server reads the raw URL string of the article to be evaluated. This URL typically contains a protocol identifier, domain name, path, and optional query parameters. The server first processes the protocol identifier, detecting whether the protocol string at the beginning of the address is "http: / / " or "https: / / ", and converts the detected protocol to HTTPS. The server uses a string substitution function to replace "http: / / " with "https: / / ", ensuring all addresses use the same protocol identifier. The server locates the question mark character in the URL; the content after the question mark is the query parameter part. The server extracts the string before the question mark as the body of the address, which contains the protocol, domain name, and path. The server removes dynamic parameters from the query parameters. These parameters typically appear with specific key names, such as utm_source, utm_medium, and utm_campaign for ad tracking, sessionid and jsessionid for session management, and ref and from for source identification. The server uses regular expressions to match the key name patterns of these dynamic parameters and removes the matched parameters and their values ​​from the query string. For the retained static parameters, the server rearranges the parameter order according to the alphabetical order of the key names to ensure consistent parameter order. The server processes the domain name portion, converting all letters to lowercase, as domain names are case-insensitive, but string comparisons are. The server checks if the domain name begins with a "www." subdomain; if so, it removes the subdomain prefix, since most websites' root domain and "www" subdomains point to the same content. The server checks for trailing forward slashes in the path, adding a trailing forward slash for directory paths and removing it for file paths, performing path normalization. The server removes the hash symbol (#) and subsequent anchor points from the URL, as anchor points are only used for page navigation and do not affect page content. The server then concatenates the processed parts in the format "protocol: / / domain / path?parameters" to generate the normalized original address.

[0055] Perform step-by-step redirection tracing on each reference source address to obtain the final landing address reached by each reference source address after redirection.

[0056] Hierarchical redirect tracing refers to the process of sequentially accessing URLs and examining the HTTP redirect responses returned by the server, tracing the redirect chain step by step until reaching the final landing page address where redirection no longer occurs. The final landing address is the URL address of the page where the actual content is returned by the server after all redirects.

[0057] The server iterates through the list of reference source addresses collected from the generative AI dialogue platform, performing redirect tracking for each address. The server initializes a redirect counter to zero and sets a maximum redirect count limit of 10 to prevent infinite redirect loops. The server constructs a HEAD request using an HTTP client library. HEAD requests only retrieve response header information and do not download page content, saving network bandwidth and processing time. The server sets the User-Agent field in the request header to simulate browser access, avoiding being identified as a crawler and having the request rejected. The server sends a HEAD request to the current reference source address, setting the request parameter to not automatically follow redirects, allowing manual control of the redirection process. The server receives the HTTP response and checks the status code field. A status code of 301 indicates a permanent redirect, 302 indicates a temporary redirect, 303 indicates viewing elsewhere, 307 indicates a temporary redirect holding the request method, and 308 indicates a permanent redirect holding the request method. The server processes these redirection status codes uniformly, extracting the value of the Location field from the response header, which contains the target URL address of the redirect. The server increments the redirect counter and checks if it exceeds the maximum number of redirects. If it doesn't, the server uses the URL in the Location field as the new request address and repeats the HEAD request and redirection detection process. If the response status code is 200, indicating a successful request, or if the status code is 404, 403, or an error code, or if the maximum number of redirects has been reached, the server stops redirect tracking and records the current address as the final landing address. The server handles relative path redirection target addresses. When the Location field value does not contain the protocol and domain name, the server converts the relative path to an absolute path according to the HTTP specification, concatenating the relative path using the protocol and domain name of the current request address. The server stores the obtained final landing address in the record corresponding to the referencing source address, establishing a mapping relationship between the referencing source address and the final landing address.

[0058] URL normalization is performed on each final landing address to remove differences in dynamic query parameters and protocol identifiers, resulting in normalized reference addresses.

[0059] A normalized URL refers to the standard URL format obtained after performing URL normalization on the final landing address of each source URL.

[0060] The server iterates through all recorded final landing addresses, performing the same normalization process as for the original address. The server uniformly converts the protocol identifier of each final landing address to HTTPS, replacing "http: / / " with "https: / / " through string substitution. The server parses the query parameters of the final landing address, identifying and removing dynamic query parameters. The server uses regular expressions to match common dynamic parameter key name patterns, including tracking parameters, session parameters, and source parameters, removing these parameters from the query string. The server converts all letters in the domain name to lowercase and removes the "www." subdomain prefix from the beginning of the domain name. The server normalizes the trailing forward slash in the path, adding a forward slash to directory paths and removing it from file paths. The server removes anchor marks and hash characters from the end of the URL. The server sorts the retained query parameters alphabetically by key name to ensure consistent parameter order. The server concatenates the processed protocol, domain name, path, and parameter parts to generate a normalized reference address. The server stores each normalized reference address in a list, establishing a ternary mapping relationship with the original reference source address and the final landing address for subsequent matching and comparison.

[0061] The normalized original URLs are matched with each normalized reference URL. The number of times the successfully matched normalized reference URLs appear in the responses returned by multiple generative AI dialogue platforms is counted, and the number of appearances is used as the article hit frequency.

[0062] String matching refers to the operation of comparing two strings character by character to determine whether their contents are completely identical. A successful match means that the character values ​​at each position in the two strings are the same, and the strings also have the same length. Article hit frequency refers to the total number of times the normalized original URL is successfully matched among various normalized citation URLs, reflecting how often the article to be evaluated is cited by the generative AI dialogue platform.

[0063] The server reads the normalized raw URL string and a list of normalized reference URL strings. The server iterates through the list of normalized reference URLs, performing a complete string match operation for each URL. The server calls a string comparison function, passing the normalized raw URL and the current normalized reference URL as parameters. The function returns a boolean value indicating whether the two strings are equal. When the function returns true, a match is successful, and the server increments the hit counter. The server continues to iterate through the next normalized reference URL, repeating the string matching and counting operations until all normalized reference URLs have been processed. The server reads stored triplet structure data, where each triple contains the query question, answer content, and source URL. The server needs to count the occurrences of successfully matched normalized reference URLs in the answer content, as the same address may be referenced in multiple answers. The server iterates through the triplet data, extracting the source URL field for each triple, which corresponds to a final landing address and a normalized reference URL. The server matches the normalized raw URL with the corresponding normalized reference URL. A successful match indicates that the answer content references the article to be evaluated. The server increments the counter for each successful match. After traversing all triples, the counter value represents the total number of times the article to be evaluated was cited in all responses. The server uses this total number as the article hit frequency, which reflects the article's exposure performance in the search results of the generative AI dialogue platform. The server stores the article hit frequency in the evaluation data structure, correlates it with other evaluation metrics of the article, and uses it to calculate the overall exposure score and generate the evaluation report.

[0064] S105. Obtain the weight data of the website where the article to be evaluated is located, and calculate the comprehensive exposure score based on the article's hit frequency and weight data.

[0065] The weighted data refers to authoritative indicators related to the website where the article to be evaluated is located, including the website's domain authority, page authority, and search engine indexing volume. The comprehensive exposure score represents the overall exposure performance score of the article to be evaluated in the AI ​​search environment.

[0066] Specifically, the server obtains the website's authority data by querying third-party SEO data services or search engine webmaster tools. The server extracts the website's domain name and calls the authority query API to obtain the domain's corresponding authority score. The server also obtains auxiliary indicators such as the number of pages indexed by major search engines, domain age, and the number of external links. After normalizing these indicators, they are weighted and combined to form a comprehensive authority coefficient. The server uses a weighted summation or weighted product method to combine the article hit frequency with the comprehensive authority coefficient. The server sets a base weight for the hit frequency and an adjustment coefficient for the website authority, and calculates the comprehensive exposure score using a formula: Comprehensive Exposure Score = Article Hit Frequency multiplied by Hit Frequency Weight + Website Authority Coefficient multiplied by Website Authority Adjustment Coefficient. The server standardizes the calculation results, mapping the score to a fixed numerical range.

[0067] In some embodiments, weight data acquisition and comprehensive exposure score calculation can be achieved in multiple ways: Optionally, the server uses a static weight configuration method, pre-setting fixed weight coefficients for websites with different weight levels, querying the corresponding weight coefficient from the configuration table based on the website's domain weight level, and multiplying the article hit frequency by this weight coefficient to obtain the comprehensive exposure score; Optionally, the server uses a dynamic weight calculation method, calling a third-party data service in real time to obtain the latest weight data of the website, performing a weighted calculation based on multiple weight indicators to obtain the comprehensive weight coefficient, and dynamically adjusting the weight coefficient while considering the differences in the website's performance on different search engines and AI platforms. It is understood that other methods can also be used to acquire weight data and calculate the comprehensive exposure score, and these are not limited here.

[0068] In some embodiments, this step specifically includes:

[0069] The site authority score of the website where the article to be evaluated is located and the average hit frequency of historically evaluated articles on multiple generative AI dialogue platforms on the website where the article to be evaluated is located are obtained, and the site authority score and average hit frequency are used as weighted data.

[0070] Site authority score is a comprehensive rating metric that measures a website's authority and influence within search engines and the internet ecosystem. This score is typically calculated by third-party SEO tools or search engines based on multiple factors, including domain age, backlink quality, content quality, and user access data. Historically evaluated articles refer to other articles from the same website that have already undergone exposure evaluation before the article to be evaluated. Average hit frequency is the arithmetic mean of the number of times historically evaluated articles are cited across multiple generative AI dialogue platforms; this value reflects the average exposure level of the website's articles in the AI ​​search environment. Weight data is a dataset containing both the site authority score and average hit frequency, used as a reference benchmark for comprehensively evaluating the exposure effect of the article to be evaluated.

[0071] The server extracts the domain name portion from the original URL of the article to be evaluated, obtaining the domain name string between the protocol identifier and the first forward slash by parsing the URL string. The server queries a site authority rating database, which stores authority rating information for each domain. These authority ratings come from third-party SEO data providers, such as Moz's Domain Authority rating, Ahrefs' Domain Rating rating, or Majestic's Trust Flow rating. The server sends a domain query request to a third-party API, with parameters including the domain name string and API key. The API returns a JSON response containing the domain's authority rating. The server extracts the rating field from the response data; this rating is typically an integer value between 0 and 100, with higher values ​​indicating higher website authority. The server stores the obtained site authority rating in a temporary variable. The server queries a historical evaluation record database, which stores records of articles that have been evaluated. Each record includes fields such as article address, domain name, evaluation time, and article hit frequency. The server constructs an SQL query, filtering based on the domain name being equal to the domain name of the article to be evaluated and the evaluation time being earlier than the current time. The server executes the query to retrieve a set of records for all historically evaluated articles under that domain. The server extracts the hit frequency field value for each article from the record set and stores these frequency values ​​in an array. The server calculates the sum of all frequency values ​​in the array and then divides it by the array length to obtain the arithmetic mean, which is the average hit frequency. When the number of historically evaluated articles is zero, the server sets the average hit frequency to a preset initial value, such as 1, to avoid division by zero errors in subsequent calculations. The server combines the site authority rating and the average hit frequency into a weighted data object, which contains two fields storing these two values ​​respectively, used for subsequent comprehensive score calculations.

[0072] The ratio of the article hit frequency to the average hit frequency is calculated to obtain the relative exposure intensity coefficient, which is used to characterize the difference in exposure ability of the article to be evaluated relative to the historical evaluated articles on the website where the article to be evaluated is located.

[0073] The relative exposure intensity coefficient is the ratio of the hit frequency of the article being evaluated to the average hit frequency of historical articles on the website. This coefficient quantifies the strength of the article's exposure ability relative to the website's average level. Exposure ability difference refers to the difference in citation frequency between the article being evaluated and historical articles on the website within the generative AI dialogue platform. A positive difference indicates that the article being evaluated has an exposure ability that is better than the average level, while a negative difference indicates that it is lower than the average level.

[0074] The server reads the article hit frequency and the average hit frequency from the weight data of the articles to be evaluated. The server performs a division operation, dividing the article hit frequency by the average hit frequency. The calculation formula is: Relative Exposure Intensity Coefficient = Article Hit Frequency Divided by Average Hit Frequency. The server handles special cases: when the average hit frequency is zero or a very small value close to zero, to avoid division by zero errors or abnormally large coefficient values, the server sets the average hit frequency to a minimum threshold of not less than 1. The calculated relative exposure intensity coefficient is a floating-point number. A coefficient greater than 1 indicates that the exposure ability of the article to be evaluated is higher than the website's historical average level; a coefficient equal to 1 indicates that the exposure ability is on par with the average level; and a coefficient less than 1 indicates that the exposure ability is lower than the average level. The server limits the numerical range of the relative exposure intensity coefficient, setting an upper limit of 5.0. When the calculated result exceeds 5.0, it is truncated to 5.0 to prevent an abnormally high frequency of individual articles from causing an excessively large coefficient and affecting the stability of the scoring. The server stores the calculated relative exposure intensity coefficient in the evaluation data structure. This coefficient serves as an intermediate calculation result in generating the overall exposure score and also as an indicator in the evaluation report, helping users understand the performance differences of the evaluated article relative to other articles on the website. The calculation of the relative exposure intensity coefficient eliminates the influence of differences in authority between different websites, allowing articles from websites with different levels of authority to be compared horizontally on the same benchmark, reflecting the actual contribution of article content quality and optimization effects to exposure.

[0075] The comprehensive exposure score is calculated based on the relative exposure intensity coefficient and the site's authoritative rating.

[0076] The comprehensive exposure score is a comprehensive score index calculated by taking into account the relative exposure intensity coefficient and the site authority score. This score reflects both the article's own exposure ability and the overall authority of the website.

[0077] The server reads the site authority rating from the relative exposure intensity coefficient and weight data. Since the relative exposure intensity coefficient ranges from 0 to 5.0, which differs in dimensions from the site authority rating range of 0 to 100, the server first normalizes the relative exposure intensity coefficient by dividing it by a preset upper limit of 5.0 to obtain the normalized exposure coefficient, which ranges from 0 to 1. Simultaneously, the server normalizes the site authority rating by dividing it by 100 to convert it to a range of 0 to 1, obtaining the normalized authority coefficient. The server then calculates the comprehensive exposure score using a weighted summation method: the comprehensive exposure score equals the normalized exposure coefficient multiplied by the exposure weight plus the normalized authority coefficient multiplied by the authority weight, multiplied by 100. The server sets the exposure weight to 0.6 and the authority weight to 0.4, with the sum of the exposure weight and the authority weight equal to 1. This weighting distribution prioritizes the article's own exposure ability while providing a foundational support from the website's authority. The specific calculation process is as follows: The server divides the relative exposure intensity coefficient by 5.0 to obtain the normalized exposure coefficient, and divides the site authority score by 100 to obtain the normalized authority coefficient. Then, it calculates the weighted sum of the normalized exposure coefficient multiplied by 0.6 and the normalized authority coefficient multiplied by 0.4. Finally, it multiplies the weighted sum by 100 to map it to the standard score range of 0 to 100. Since the normalized exposure coefficient and the normalized authority coefficient both range from 0 to 1, and the sum of the exposure weight and the authority weight is 1, the weighted sum ranges from 0 to 1. After multiplying by 100, the comprehensive exposure score is strictly limited to the range of 0 to 100, without the need for additional boundary truncation.

[0078] For example, suppose an article to be evaluated has a hit frequency of 12 times, the historical average hit frequency of evaluated articles on the website is 8 times, and the site's authority score is 75. The server first calculates the relative exposure intensity coefficient, which is 12 divided by 8, equaling 1.5. Then, it calculates the normalized exposure coefficient, which is 1.5 divided by 5.0, equaling 0.3. The normalized authority coefficient is 75 divided by 100, equaling 0.75. Finally, the comprehensive exposure score is calculated as 0.3 multiplied by 0.6, plus 0.75 multiplied by 0.4, then multiplied by 100 (i.e., 0.18 plus 0.3 multiplied by 100), equaling 48.0 points. This score indicates that the overall exposure effect of the article to be evaluated in the AI ​​search environment is at a medium level.

[0079] The server performs numerical precision processing on the comprehensive exposure score, retaining one decimal place and rounding to obtain the final score value. The server stores the calculated comprehensive exposure score in the core indicator field of the evaluation data structure; this score serves as the final quantitative result of the article's exposure effect. The server displays the comprehensive exposure score in the evaluation report, along with a level description, such as a score between 80 and 100 being excellent, 60 to 80 being good, 40 to 60 being average, 20 to 40 being poor, and 0 to 20 being very poor. The server simultaneously presents the relative exposure intensity coefficient, site authority score, and comprehensive exposure score in the report, helping users fully understand the components of the score and the multi-dimensional characteristics of the article's exposure performance.

[0080] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the article AI search exposure effect evaluation method based on GEO in this application embodiment.

[0081] S201. Obtain the title text and body text of the article to be evaluated. Use the title text as the main extraction object and the body text as the auxiliary extraction object for semantic parsing to extract the core promotion entity and related attribute descriptions.

[0082] Title text refers to the title of an article, while body text refers to the main content. Semantic parsing refers to the process of analyzing text using natural language processing techniques to identify entities, attributes, and their semantic relationships. The core promotional entity refers to the main object extracted from the article that best represents the article's promotional goals, such as a product name or brand name. Related attribute descriptions refer to descriptive information related to the core promotional entity, such as the product's features or application scenarios.

[0083] The server obtains the complete URL of the article to be evaluated, accesses the URL using web crawling technology, parses the webpage structure, and extracts text data corresponding to title tags and body content tags from the HTML document. The server then uses a natural language processing model to perform deep analysis on the title text, identifying named entities, verb phrases, and noun phrases, and identifying the entities with the highest frequency or semantic weight as core promotion entities. For the body text, the server extracts paragraph content related to the title theme, identifies adjectives, adverbs, and prepositional phrases modifying the core promotion entities through dependency parsing, and categorizes these modifiers into related attribute descriptions. The server uses the TF-IDF algorithm to calculate word importance, and combines this with part-of-speech tagging results to filter out attribute words with actual semantic value, while filtering out stop words and function words. The server employs a rule-based approach, pre-defining an entity recognition rule base and an attribute extraction pattern base. It matches the title text against patterns in the rule base and extracts the core promotional entity and associated attribute descriptions from the matching locations. Alternatively, it uses a deep learning-based named entity recognition model, inputting the title and body text into a pre-trained BERT model. The model's encoding layer obtains the context vector representation of each word, which is then input into the entity classification layer to identify entity boundaries and entity types. From the recognition results, product or brand entities are selected as core promotional entities, while modifiers surrounding the entities are extracted as associated attribute descriptions.

[0084] S202. Combine the core promotion entity with the attribute words in the associated attribute description to generate multiple query seed words.

[0085] Concatenation and combination refers to the operation of connecting two or more text fragments according to certain rules to form a new text string. Query seed keywords are basic keywords generated based on the core promoted entity and related attribute descriptions, used for subsequent query expansion. These seed keywords contain core entity information and attribute characteristics, and can represent the user's potential search intent.

[0086] The server preprocesses the extracted core promotion entities and related attribute descriptions, removing punctuation and special characters and converting the text to a standard encoding format. The server then concatenates the core promotion entities with each attribute word using a permutation and combination method, adding spaces as separators between the entities and attribute words to generate query seed words in the form of "core promotion entity attribute words". The server places the core promotion entity at the beginning of the concatenation result to ensure that the generated query seed words conform to users' natural search habits. The server pairs multiple attribute words in the related attribute descriptions, concatenating the core promotion entity with a single attribute word and combinations of two attribute words to generate query seed words of different granularities. The server deduplicates the generated query seed words, removing semantically repetitive or similarly expressed seed words and retaining those with distinct characteristics. The server stores all generated query seed words in a seed word set, providing foundational data for subsequent query expansion operations. In practice, the server uses a nested loop traversal method. The outer loop traverses the core promotion entity, and the inner loop traverses each attribute word in the associated attribute description. The string concatenation operation is performed in the inner loop, and the concatenation result is added to the seed word set.

[0087] S203. Call the query association interface of the target search engine with multiple query seed words respectively, and extract the related search terms displayed in the search results page of the target search engine, and gather them into a candidate query set.

[0088] The query suggestion interface refers to the API provided by the search engine. When a user enters part of a query term, this interface returns a list of popular search suggestions related to the entered term. Related search terms refer to other search terms semantically related to the current query term displayed at the bottom of the search results page; these terms reflect the user's related search needs. The candidate query set is a collection of all query terms related to the core promoted entity, obtained through various query expansion methods, used for subsequent query coverage analysis.

[0089] The server iterates through multiple generated seed keywords, constructs an HTTP request for each seed keyword, and calls the target search engine's query suggestion interface. The server sets the seed keyword as input in the request parameters, sends a GET or POST request to the suggestion interface's URL, and receives JSON data returned by the interface. The server parses the returned data structure, extracts the suggested keyword list field, and adds each suggested keyword to the candidate query set. Using web scraping technology, the server submits the seed keywords to the target search engine's search page to obtain the HTML content of the search results page. The server uses an HTML parsing library to locate the relevant search term display area on the page, typically located at the bottom of the page and identified using specific CSS class names or HTML tags. The server extracts all text links in this area and adds the link text as relevant search terms to the candidate query set. The server deduplicates all query terms in the candidate query set, removing completely duplicated terms and identifying highly similar terms by calculating edit distance or semantic similarity, retaining only the semantically complete or most frequently used query terms. In practice, the server uses multi-threading or asynchronous concurrency to process multiple query seed words in batches, improving the efficiency of query expansion. At the same time, it sets a request interval to avoid triggering the search engine's anti-crawler mechanism due to excessive request frequency.

[0090] S204. Determine the category attribute to which the core promotion entity belongs, and query the combination of intent dimensions associated with the category attribute from the preset intent dimension library as a coverage verification list. Different category attributes in this intent dimension library correspond to different combinations of intent dimensions, and each intent dimension is configured with a corresponding set of feature words.

[0091] Category attributes refer to category tags used to classify and label core promoted entities, such as classifying entities into categories like electronics, food and beverages, or clothing and footwear. Intent dimensions refer to the different information needs of users during searches, such as review needs, price needs, purchase channel needs, or usage tutorial needs. An intent dimension library is a pre-built knowledge base that stores combinations of intent dimensions corresponding to different category attributes, as well as the set of feature words associated with each intent dimension. A coverage verification checklist is a list of all intent dimensions and their feature words that need to be covered for the current core promoted entity's category attributes, used for subsequent evaluation of the coverage of the candidate query set.

[0092] The server performs category identification on the extracted core promotional entities, determining the entity's category attribute through a pre-trained classification model or rule matching method. The server inputs the core promotional entities into a text classification model, which outputs the entity's category tag and its confidence score. The server selects the category tag with the highest confidence score as the category attribute. The server queries a pre-defined intent dimension library for intent dimension combinations associated with the category attribute. The intent dimension library uses a key-value pair structure, with the category attribute as the key and the corresponding intent dimension combination as the value. The server reads the query results, obtaining all intent dimensions under the category attribute. For example, for the electronics category, intent dimension combinations include performance evaluation, price comparison, purchase channels, user guides, and after-sales service. The server further reads the feature word set configured for each intent dimension. For example, the feature words corresponding to the performance evaluation dimension include words such as "how," "evaluation," "test," "performance," and "configuration." The server organizes the obtained intent dimensions and their feature word sets into a coverage verification checklist, where each intent dimension corresponds to a feature word list. In practice, the intent dimension library is stored in a relational database or a NoSQL database. The server retrieves records that match the category attributes from the database through SQL queries or key-value queries, and loads the query results into memory to form a coverage verification list.

[0093] S205. Detect whether each candidate query in the candidate query set contains the feature words corresponding to each intent dimension in the coverage checklist, and classify the candidate queries containing the feature words into the corresponding intent dimension.

[0094] Feature words are keywords that can characterize a specific intent dimension. When a query contains these feature words, it indicates that the query matches the corresponding intent dimension. The assignment operation refers to assigning candidate queries that match a specific intent dimension to that intent dimension, establishing a mapping relationship between queries and intent dimensions.

[0095] The server iterates through each candidate query in the candidate query set, performing feature word matching detection on each. It also iterates through all intent dimensions in the coverage verification list, reading the corresponding feature word set for each intent dimension. The server uses a string matching algorithm to check whether each candidate query contains any feature word from the feature word set, employing full-character matching to ensure that the feature word appears as a complete word in the candidate query. The server uses a word segmentation tool to segment the candidate query into word sequences, comparing each word in the sequence with the feature words in the feature word set. When a candidate query is detected to contain a feature word from a specific intent dimension, the server assigns the candidate query to that intent dimension, establishing a relationship between the intent dimension and the candidate query. The server stores the assignment results in a mapping table, where the key is the intent dimension identifier and the value is the list of candidate queries assigned to that dimension. The server counts the number of candidate queries assigned to each intent dimension and records the results in a dimension coverage statistics table. For candidate queries containing feature words from multiple intent dimensions, the server assigns the query to multiple intent dimensions simultaneously, achieving a one-to-many mapping relationship. In practice, the server uses a hash table or dictionary structure to store the mapping relationship, with the intent dimension identifier as the key and the candidate query list as the value, supporting fast retrieval and update operations.

[0096] S206. Traverse all intent dimensions in the coverage verification list, determine intent dimensions with zero or less than the preset coverage threshold as intent dimensions to be supplemented, and count the number of candidate queries under each intent dimension to evaluate query coverage.

[0097] Intent dimensions to be supplemented refer to intent dimensions that are insufficiently covered in the candidate query set, meaning the number of candidate queries belonging to this dimension is zero or lower than the preset minimum coverage requirement. Query coverage refers to the degree to which the candidate query set covers all intent dimensions, and is quantitatively evaluated by statistically analyzing the number of candidate queries under each intent dimension.

[0098] The server iterates through all intent dimensions in the coverage verification list, retrieving the candidate query list for each intent dimension from the mapping table. The server counts the number of candidate queries in the list and compares the result with a preset coverage threshold. The coverage threshold is a pre-defined minimum query count requirement, for example, at least 3 candidate queries per intent dimension. When the number of candidate queries for an intent dimension is zero, the server directly classifies that dimension as an intent dimension to be supplemented. Similarly, when the number of candidate queries for an intent dimension is greater than zero but less than the coverage threshold, the server also classifies that dimension as an intent dimension to be supplemented. The server aggregates all intent dimensions identified as needing supplementation into a list of intent dimensions to be supplemented, which guides subsequent query supplementation operations. The server calculates the overall query coverage score using the formula: Query coverage equals the number of intent dimensions whose query count reaches the threshold divided by the total number of intent dimensions in the coverage verification list, multiplied by 100 to convert the result to a percentage. The server records the specific query count for each intent dimension and generates a coverage analysis report, which lists the name, feature set, number of candidate queries included, and the result of whether the coverage threshold has been reached for each intent dimension. In practice, the server uses a loop to process each intent dimension in turn, identifies the intent dimensions to be supplemented through conditional statements, stores the judgment results in a boolean field, and finally filters out the intent dimensions that need to be supplemented through filtering operations and outputs detailed statistical data.

[0099] S207. The intent dimensions with fewer candidate queries than the preset coverage threshold are identified as intent dimensions to be supplemented. Based on the preset query template corresponding to the intent dimensions to be supplemented, the core promotion entities are filled into the entity slots of the preset query template to generate supplementary query statements. The supplementary query statements are added to the candidate query set to obtain multiple query questions.

[0100] A preset query template is a predefined framework of query statements containing fixed sentence structures and variable slots, used to standardize the generation of query questions that conform to specific intent dimensions. Entity slots are placeholder positions reserved in the query template to fill in core promotional entities, usually indicated by special symbols. Supplementary query statements are complete query questions generated by filling the preset query template with core promotional entities, used to supplement the query coverage of intent dimensions to be supplemented.

[0101] The server iterates through the list of intent dimensions to be supplemented, retrieving the corresponding preset query template from the query template library for each intent dimension. The query template library is organized by intent dimension, with each intent dimension associated with multiple preset query templates. Each template contains fixed sentence structures such as interrogative words, verbs, and prepositions, as well as entity slots marked with curly braces or other symbols. The server reads the text content of the query template and locates the entity slot markers within the template using regular expressions or string matching methods. The server replaces the entity slot markers with the text content of the core promotion entity, generating a complete supplementary query statement. For query templates containing multiple entity slots, the server fills the main entity slot with the core promotion entity and the attribute words from the associated attribute descriptions into the attribute slots. The server performs a syntax check on the generated supplementary query statements, verifying their completeness and semantic rationality, and filtering out queries with grammatical errors or semantic inconsistencies. The server adds the verified supplementary query statements to the candidate query set and updates the number of candidate queries for that intent dimension. The server repeats the above operations until the number of queries for all intent dimensions to be supplemented reaches the coverage threshold, or all preset query templates for that dimension have been used up. The server organizes the expanded candidate query set into a query question list, with each query question in the list associated with its corresponding intent dimension identifier. In practice, the query template library is stored in JSON or XML format. The server reads the template content by parsing the configuration file, performs slot filling operations using string replacement functions, and stores the generated supplementary query statements in a list or array data structure for easy batch processing later.

[0102] S208. Send multiple query questions to multiple generative AI dialogue platforms for online search, obtain the answer content returned by the generative AI dialogue platform, and extract the source address from the answer content.

[0103] A generative AI dialogue platform refers to an AI-powered dialogue system with natural language understanding and generation capabilities. It can receive user queries, retrieve relevant information through online searches, and then generate responses. Online search refers to the process by which the generative AI dialogue platform uses search engines or accesses internet resources to retrieve web page content and data related to the query. Response content refers to the natural language reply text generated by the generative AI dialogue platform based on online search results, addressing the query. The source URL refers to the web page URL that the generative AI dialogue platform marks in the response content as the source of the information.

[0104] The server generates multiple queries and sends them to several pre-configured generative AI dialogue platforms via API interfaces or automated scripts. For each query, the server creates an independent session request, setting an flag in the request parameters to enable online search functionality. This flag instructs the platform to retrieve internet resources when generating the answer. The server submits the queries to the dialogue interfaces of each platform via HTTP, with the request body containing the query text and session configuration parameters, and sends the request data in JSON format using the POST method. The server receives response data from the platforms, containing the answer content text and metadata information, encapsulated in JSON or HTML format. The server parses the structure of the response data, extracting the text value of the answer content field, which contains the complete answer paragraph generated by the platform. The server identifies citation markers in the answer content. Citation markers typically appear in the answer text as superscript numbers, square bracket numbers, or hyperlinks, used to associate citation source addresses. The server uses regular expressions to match patterns in the citation markers and extracts the corresponding URL addresses. For hyperlink citations, the server parses the href attribute value in the HTML tag to obtain the URL address. For numbered citations, the server searches for the URL address corresponding to the number in the citation list field of the response data. The server associates the extracted source URLs with the query questions and answers, storing this association in a triple structure. Each triple contains the query question, the answer content, and a list of source URLs. In practice, the server sends query questions in batches asynchronously and concurrently, using multithreading or coroutines to simultaneously initiate session requests to multiple generative AI dialogue platforms. When a platform returns a response, a callback function is triggered to parse the data and extract the source URLs, improving processing efficiency.

[0105] S209. Match and compare the original URL of the article to be evaluated with the source URL, and count the number of times the original URL appears in the response content returned by multiple generative AI dialogue platforms to obtain the article hit frequency.

[0106] The original URL refers to the actual URL address of the article being evaluated on the internet. Matching and comparison refers to the process of comparing two URL addresses to determine whether they point to the same webpage resource. Article hit frequency refers to the total number of times the original URL of the article being evaluated appears as a source URL in all the responses returned by multiple generative AI dialogue platforms.

[0107] The server preprocesses the original URL of the article to be evaluated, removing tracking parameters, session identifiers, and anchor tags from the URL. These parameters are typically appended to the URL as key-value pairs starting with a question mark or hash symbol. The server converts the protocol identifier to HTTPS format, standardizes the www prefix in the domain name, and removes the trailing slash from the URL, resulting in a normalized original URL. The server iterates through all source URLs collected from various generative AI dialogue platforms, performing the same normalization process on each source URL. The server performs a string-by-string match between the normalized original URL and each normalized source URL, comparing characters to determine if the domain name and path portions of the two addresses are completely identical. When the string values ​​of the two addresses are exactly the same, the server determines a successful match and marks the source URL as a hit. For source URLs that do not directly match, the server performs HTTP request tracing, sending a HEAD request to the source URL, obtaining the redirect response header returned by the server, and extracting the URL value from the Location field of the response header as the final landing address after redirection. The server normalizes the final landing address and then matches it against the original URL again. The server counts the occurrences of all successfully matched source URLs in the answer content. It iterates through the stored triplet structure, summing the occurrences of the original URL as the source URL to obtain the article hit frequency. Specifically, the server uses a hash table to store the normalized original URLs as keys and a hit counter as values. When iterating through the list of source URLs, the counter is incremented for each successfully matched URL. After the iteration is complete, the counter value is read as the article hit frequency.

[0108] S210. Obtain the weight data of the website where the article to be evaluated is located, and calculate the comprehensive exposure score based on the article's hit frequency and weight data.

[0109] Weighted data refers to authoritative indicators related to the website where the article to be evaluated is located, including numerical indicators such as website domain authority, page authority, and search engine indexing volume. The comprehensive exposure score is a numerical score calculated by comprehensively considering the article's hit frequency and website authority data, used to quantitatively evaluate the article's exposure performance in an AI search environment.

[0110] The server extracts the original URL of the article to be evaluated, parses the URL string to obtain the domain name portion, which is located between the protocol identifier and the path. The server queries a third-party SEO data service or search engine webmaster tools to obtain the domain's corresponding weight data. The server calls the weight query API interface, passing the domain name string as a request parameter, and receives the weight data returned by the API. This data includes indicators such as domain weight value, page weight value, number of pages indexed by search engines, domain registration age, and number of external backlinks. The server normalizes the obtained weight indicators, mapping indicator values ​​with different dimensions to the same numerical range; for example, normalizing the domain weight value range from 0 to 100 to 0 to 1. The server sets weight coefficients for each weight indicator, reflecting the contribution of different indicators to the overall weight; for example, the domain weight coefficient is set to 0.4, the page weight coefficient to 0.3, the number of indexed pages coefficient to 0.2, and the domain registration age coefficient to 0.1. The server calculates the overall weight value using the formula: the overall weight value equals the weighted sum of each normalized indicator value multiplied by its corresponding weight coefficient. The server uses a weighted calculation method, combining article hit frequency and overall weight value, to calculate the comprehensive exposure score. The calculation formula is: Comprehensive exposure score = Article hit frequency multiplied by hit frequency weight + Overall weight value multiplied by weight adjustment coefficient, where the hit frequency weight is set to 0.7 and the weight adjustment coefficient is set to 0.3. The server standardizes the calculation results, mapping the score value to a fixed numerical range of 0 to 100. The mapping formula is: Standardized score = Original score divided by the maximum possible score value multiplied by 100. In practice, the server takes article hit frequency, overall weight value, weight coefficients, and calculation formula as input parameters, performs weighted summation and normalization calculations through mathematical operation functions, and finally outputs the numerical result of the comprehensive exposure score, which is saved in the evaluation report.

[0111] After step S210, the method further includes:

[0112] Addresses that fail to match the original address of the article to be evaluated from the source address are identified as competing reference addresses. Each competing reference address is then subjected to hierarchical redirection tracing and URL normalization to obtain the normalized competing landing addresses.

[0113] Competitive referencing URLs refer to URLs that fail to match the original URL of the article being evaluated; these URLs represent article pages from other competing websites. Hierarchical redirect tracing refers to the process of sequentially accessing URLs and tracking the HTTP redirect responses returned by the server until the final landing page address is obtained. URL normalization refers to the standardization transformation of URL addresses, including operations such as unifying protocols, removing tracking parameters, standardizing domain name formats, and removing redundant characters. A normalized competitive landing address is the standard URL address pointing to the actual content page, obtained after redirect tracing and normalization.

[0114] The server iterates through the entire list of citation source addresses collected from the generative AI dialogue platform, performing string matching on each one against the normalized original address of the article to be evaluated. The server adds citation source addresses that fail to match to the competing citation address list. The server then iterates through the competing citation address list, constructing an HTTP HEAD request for each address, setting request parameters that do not follow redirects, sending the request to the address, and receiving the response. The server checks the response status code; when the status code is 301, 302, 303, 307, or 308, it extracts the redirect target address from the Location field of the response header. The server uses the redirect target address as the new request address and continues to send HEAD requests, repeating the above redirection detection process until the response status code is 200 or the preset maximum number of redirects is reached. The server records the final landing page address and performs normalization processing on that address. Normalization includes converting HTTP to HTTPS, converting domain names to lowercase, removing the www subdomain prefix, removing trailing forward slashes and hash symbols from URLs, and removing UTM tracing parameters and session ID parameters from URLs. These parameters appear as keys such as utm_source, utm_medium, and sessionid in the query string. The server stores the normalized addresses as normalized landing addresses and aggregates all normalized landing addresses into a list.

[0115] The standardized competitive landing addresses are aggregated and grouped according to the domain name dimension. Addresses with the same path identifier under the same domain name are merged and deduplicated. The addresses that are retained after deduplication are treated as independent competitive articles, and the competitive articles are aggregated to obtain a set of competitive articles.

[0116] Domain-level grouping refers to using the domain name portion of a URL as the basis for grouping. Aggregation grouping refers to the operation of grouping URLs with the same domain name into the same group. Path identifier refers to the path portion after the domain name in a URL address, used to identify the specific page location within the website. Merging and deduplication refers to the operation of identifying and deleting duplicate or highly similar addresses, retaining only unique addresses. Competitive articles refer to independent article pages published by competing websites that have a similar topic to the article being evaluated. The competitive article collection refers to the collection of all competitive article addresses retained after deduplication.

[0117] The server iterates through the list of normalized competitive landing addresses, extracting the domain name portion from each address. The server parses the URL string, locating the string between the double forward slashes after the protocol identifier and the path separator as the domain name. The server creates a hash table structure with domain names as keys and address lists as values, iterates through the normalized competitive landing addresses, and adds addresses with the same domain name to the address list under the corresponding domain name key, completing the aggregation and grouping at the domain level. The server iterates through the address list corresponding to each domain name in the hash table, extracting the path identifier portion from the addresses in the list. The path identifier includes the path level and filename, but excludes query parameters and anchors. The server compares the path identifiers of addresses under the same domain name, identifying addresses with identical path identifiers as duplicate addresses. The server performs deduplication on duplicate addresses, retaining the first occurrence of the address in the list and deleting subsequent duplicates. The server treats each retained address after deduplication as an independent competitive article, aggregating all competitive article addresses to form a competitive article set. The server assigns a unique identifier to each competitive article, establishing a mapping relationship between competitive article addresses and identifiers for subsequent statistical analysis.

[0118] The frequency of each competing article appearing in the response content is calculated by counting the number of times each competing article appears in the set of competing articles.

[0119] The frequency of occurrence refers to the cumulative number of times a competing article's URL appears as a source of citation in all responses returned by the generative AI dialogue platform. The frequency of competition hits refers to the total number of times a single competing article is cited across multiple responses, reflecting the article's exposure frequency in AI search results.

[0120] The server iterates through each competing article URL in the collection, counting the number of times each URL appears in the answer content. The server reads stored triplet structure data, where each triple contains the query question, answer content, and a list of citation URLs. The server iterates through all triplet records, extracts the citation URL list field, and matches it against the current competing article URL. When the citation URL list contains the current competing article URL, the server increments the counter for that competing article. The server uses a hash table to store the statistical results, with the competing article URL as the key and the occurrence count as the value. After iterating through all triplet records, the server reads the counter value corresponding to each competing article URL in the hash table and uses this value as the competition hit frequency. The server establishes a mapping table between competing article URLs and their competition hit frequencies, which is used for subsequent ranking calculations and report generation.

[0121] The article hit frequency and the hit frequency of each competitor are sorted in descending order to generate a competitive exposure ranking. The competitive exposure ranking and the comprehensive exposure score are output as an exposure effect evaluation report.

[0122] Descending sort refers to sorting data in descending order of numerical value. Competitive exposure ranking refers to the ranking order obtained by sorting articles in descending order of their hit frequency and the competitive hit frequency of each competing article. Exposure effectiveness evaluation report is a structured report document that includes the overall exposure score of the article to be evaluated, its hit frequency, competitive exposure ranking, and detailed information about competing articles.

[0123] The server merges the article hit frequency of the article to be evaluated with the competitive hit frequency of each competing article in the competing article set into a unified data list. Each record in the data list contains three fields: article identifier, article address, and hit frequency. The server sorts the data list in descending order according to the hit frequency field, using either quicksort or mergesort algorithms, placing records with higher hit frequencies at the top and those with lower hit frequencies at the bottom. The server assigns a ranking number to the sorted list, with the first record ranked 1, the second 2, and so on. For records with the same hit frequency, the server performs a secondary sort of the addresses alphabetically and assigns the same ranking value. The server finds the ranking position of the article to be evaluated from the sorting results and uses this ranking as the competitive exposure ranking. The server generates an exposure effect evaluation report, in JSON or PDF format. The first part of the report contains basic information fields for the article to be evaluated, including the article title, original address, core promotion entity, category attribute, and evaluation time. The second part of the report contains exposure metric data, including article hit frequency, overall exposure score, and competitive exposure ranking. The third part of the report contains competitive analysis data, listing the top ten competing articles. Each competing article includes four fields: address, domain name, competition hit frequency, and ranking. The fourth part of the report contains coverage analysis data, listing the query coverage for each intent dimension and a list of intent dimensions to be supplemented. The server saves the generated report file to the specified storage path and returns the report's access address.

[0124] The server in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference]. Figure 3 This is a schematic diagram of the physical device structure of a server in an embodiment of this application.

[0125] It should be noted that, Figure 3 The server structure shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0126] like Figure 3 As shown, the server includes a CPU 301, which can perform various appropriate actions and processes according to a program stored in ROM 302 or a program loaded into RAM 303 from storage section 308, such as performing the methods described in the above embodiments. RAM 303 also stores various programs and data required for system operation. CPU 301, ROM 302, and RAM 303 are interconnected via bus 304. I / O interface 305 is also connected to bus 304.

[0127] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including hard disks, etc.; and communication section 309 including network interface cards such as LAN (Local Area Network) cards, modems, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0128] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by CPU 301, it performs the various functions defined in the present invention.

[0129] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0130] Specifically, the server in this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the article AI search exposure effect evaluation method based on GEO provided in the above embodiment.

[0131] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the server described in the above embodiments; or it may exist independently and not assembled into the server. The storage medium carries one or more computer programs that, when executed by a processor of the server, cause the server to implement the GEO-based article AI search exposure effect evaluation method provided in the above embodiments.

[0132] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0133] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

Claims

1. A method for evaluating the exposure effect of article AI search based on GEO, characterized in that, Applied to a server, the method includes: Obtain the title text and body text of the article to be evaluated. Use the title text as the main extraction object and the body text as the auxiliary extraction object for semantic parsing to extract the core promotion entity and related attribute description. Based on the core promotion entity and the associated attribute description, multiple query questions are constructed according to the user information acquisition scenario; Multiple query questions are sent to multiple generative AI dialogue platforms for online searching, and the answer content returned by the generative AI dialogue platform is obtained. The source address of the reference is extracted from the answer content. The original URL of the article to be evaluated is matched and compared with the source URL, and the number of times the original URL appears in the response content returned by multiple generative AI dialogue platforms is counted to obtain the article hit frequency. Obtain the weight data of the website where the article to be evaluated is located, and calculate the comprehensive exposure score based on the article's hit frequency and the weight data.

2. The method according to claim 1, characterized in that, The step of constructing multiple query questions based on the core promotion entity and the associated attribute description, according to the user information acquisition scenario, specifically includes: The core promotion entity is concatenated and combined with the attribute words in the associated attribute description to generate multiple query seed words; The query association interface of the target search engine is called with the multiple query seed words respectively, and the related search words displayed in the search results page of the target search engine are extracted and aggregated into a candidate query set; Based on a preset user intent dimension system, each candidate query in the candidate query set is classified according to intent dimension, and the number of candidate queries under each intent dimension is counted to evaluate query coverage. The intent dimensions with fewer candidate queries than a preset coverage threshold are identified as intent dimensions to be supplemented. Based on the preset query template corresponding to the intent dimensions to be supplemented, the core promotion entity is filled into the entity slot of the preset query template to generate a supplementary query statement. The supplementary query statement is added to the candidate query set to obtain the multiple query questions.

3. The method according to claim 2, characterized in that, The step of classifying each candidate query in the candidate query set according to the intent dimension based on the preset user intent dimension system specifically includes: The category attribute to which the core promotion entity belongs is determined, and the combination of intent dimensions associated with the category attribute is queried from the preset intent dimension library as a coverage verification list. Different category attributes in the intent dimension library correspond to different combinations of intent dimensions, and each intent dimension is configured with a corresponding set of feature words. Detect whether each candidate query in the candidate query set contains the feature words corresponding to each intent dimension in the coverage verification list, and classify the candidate queries containing the feature words into the corresponding intent dimension; Traverse all intent dimensions in the coverage verification list, and determine the intent dimensions that have zero or less than the preset coverage threshold as the intent dimensions to be supplemented.

4. The method according to claim 1, characterized in that, The step of matching and comparing the original address of the article to be evaluated with the source address of the cited article, and counting the number of times the original address appears in the responses returned by the multiple generative AI dialogue platforms to obtain the article hit frequency, specifically includes: The original URL of the article to be evaluated is URL normalized to remove dynamic query parameters and protocol identifier differences in the original URL, resulting in a normalized original URL. Perform step-by-step redirection tracing on each of the aforementioned source addresses to obtain the final landing address reached by each of the aforementioned source addresses after redirection; The URL normalization process is performed on each of the final landing addresses to remove the differences in dynamic query parameters and protocol identifiers in each of the final landing addresses, thereby obtaining each normalized reference address; The normalized original address is matched with each of the normalized reference addresses. The number of times the successfully matched normalized reference addresses appear in the answers returned by the multiple generative AI dialogue platforms is counted, and the number of appearances is used as the article hit frequency.

5. The method according to claim 1, characterized in that, The step of obtaining the weight data of the website where the article to be evaluated is located, and calculating the comprehensive exposure score based on the article's hit frequency and the weight data, specifically includes: The site authority score of the website where the article to be evaluated is located and the average hit frequency of historically evaluated articles on the website where the article to be evaluated is located are obtained, and the site authority score and the average hit frequency are used as the weight data. The ratio of the article hit frequency to the average hit frequency is calculated to obtain the relative exposure intensity coefficient, which is used to characterize the difference in exposure ability of the article to be evaluated relative to the historically evaluated articles on the website where the article to be evaluated is located. The comprehensive exposure score is calculated based on the relative exposure intensity coefficient and the site authority score.

6. The method according to claim 1, characterized in that, After the steps of obtaining the weight data of the website where the article to be evaluated is located, and calculating the comprehensive exposure score based on the article's hit frequency and the weight data, the method further includes: The addresses in the source address that fail to match the original address of the article to be evaluated are identified as competing reference addresses. The competing reference addresses are then subjected to domain aggregation and page deduplication to obtain a set of competing articles. The frequency of each competing article in the answer content is obtained by counting the number of times each competing article appears in the set of competing articles. The article hit frequency and the hit frequency of each competitor are sorted in descending order to generate a competitive exposure ranking. The competitive exposure ranking and the comprehensive exposure score are output as an exposure effect evaluation report.

7. The method according to claim 6, characterized in that, The step of performing domain aggregation and page deduplication on the competing reference addresses to obtain a set of competing articles specifically includes: Perform step-by-step redirection tracing and URL normalization on each of the competing reference addresses to obtain the normalized competing landing addresses; The standardized competitive landing addresses are aggregated and grouped according to the domain name dimension. Addresses with the same path identifier under the same domain name are merged and deduplicated. Each address retained after deduplication is regarded as an independent competitive article, and the competitive articles are summarized to obtain the competitive article set.

8. A server, characterized in that, The server includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the server to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the server, the server causes the server to perform the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the server, the server performs the method as described in any one of claims 1-7.

Images