Facebook inquiry auto-distribution methods, devices and electronic equipment

Abstract

This application discloses a method, apparatus, and electronic device for automatically assigning Facebook queries, relating to the field of computer information processing technology. The method includes: acquiring a form to be assigned; acquiring available members and forming an ordered attempt queue according to a preset sorting field; determining the starting attempt position based on an assignment pointer that records the sorting field value of the last successfully assigned member; and executing assignment attempts sequentially, including creating leads, updating the count and assignment pointer upon success, and writing the form identifier to a failure cache and continuing to try the next member upon failure. Reassignment is allowed as long as the retry count has not reached a preset retry limit, and forms that have reached the preset retry limit are removed from the assignment queue. This decouples the assignment progress from member identification, ensures automatic recovery of breakpoints after member deletion, and curbs the unlimited consumption of system resources by failed forms through a limited retry mechanism. The synergistic effect of these two mechanisms systematically improves the robustness of automated assignment operation.

Description

Technical Field

[0001] This invention relates to the field of computer information processing technology, and specifically to a method, apparatus, and electronic device for automatically assigning Facebook queries. Background Technology

[0002] Facebook ads are one of the important channels for foreign trade companies to obtain inquiries from overseas customers. Companies use Facebook ads to collect information on potential customers (called "forms" or "inquiries"), and then assign these inquiries to sales staff for follow-up.

[0003] Existing Facebook inquiry auto-distribution solutions primarily use a round-robin mechanism, assigning inquiries sequentially to each salesperson. The system needs to record the position of the member in the last assignment so that the next assignment continues from that position, thereby maintaining the evenness of the distribution.

[0004] However, the existing polling allocation mechanism has systemic defects in the reliability of automated operation under abnormal scenarios, specifically manifested in the following two interrelated problems: On the one hand, maintaining the allocation progress is highly dependent on member identification. The system typically records the "last allocated member ID" as a breakpoint. When a member is deleted or deactivated due to resignation, job transfer, or other reasons, the system cannot find the corresponding record in the existing member list, resulting in the loss of the breakpoint and forcing the allocation process to start from scratch. This not only undermines the fairness of polling but may also lead to system malfunctions or require manual intervention to restore operation.

[0005] On the other hand, the system lacks a closed-loop handling mechanism for allocation failure events. During the lead creation process, allocation may fail due to reasons such as interface exceptions or data validation failures. Existing solutions typically only perform simple rollbacks or re-queueing for such failed forms, causing them to be repeatedly tried in subsequent allocation tasks. This infinite retries continuously consume system computing resources and interface call quotas, and generate a large number of duplicate error logs, which may eventually cripple related services.

[0006] The two issues mentioned above together reveal the essential defects of the existing technology: the maintenance of the allocation schedule lacks a decoupled design from the member identity, and the exception handling lacks self-healing and termination strategies, which leads to the system interrupting the allocation schedule or falling into an invalid loop when encountering member changes or operation failures, resulting in poor reliability of automated operation.

[0007] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the embodiments of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0008] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0009] This disclosure provides a method, system, and electronic device for automatically allocating Facebook inquiries, aiming to solve the technical problem of poor reliability in the automated operation of the existing Facebook inquiry polling and allocation process. This is because the allocation progress maintenance relies on member identity identifiers and lacks an abnormal self-healing mechanism, which leads to the system experiencing allocation progress interruption or falling into an invalid retry loop in abnormal scenarios such as member deletion or lead creation failure.

[0010] In some embodiments, a method for automatically assigning Facebook inquiries includes: Retrieve Facebook inquiry forms to be assigned; Obtain the available members bound by the allocation rules, sort the available members according to the preset sorting field, and form an ordered attempt queue; Determine the starting position for this allocation attempt: if the allocation pointer maintained by the system exists, start from the first member in the attempt queue whose sort field value is greater than the value recorded by the allocation pointer; otherwise, start from the first member in the attempt queue; wherein, the allocation pointer records the sort field value corresponding to the member that was successfully allocated last time; Starting from the initial attempt position, each member in the attempt queue is assigned in sequence until the assignment is successful or the attempt queue has been traversed. The allocation attempt includes: performing a clue creation operation on the current member; if the creation is successful, updating the current member's allocated count and updating the allocation pointer to the current member's sort field value, ending the current allocation; if the creation fails, writing the form's identification information into the failure cache and continuing to try the next member; wherein, the forms in the failure cache are allowed to be reassigned when the retry count has not reached the preset retry limit, and are removed from the allocation queue after reaching the limit.

[0011] In some embodiments, a Facebook query auto-distribution device includes: The form retrieval module is used to retrieve Facebook inquiry forms to be assigned. The member sorting module is used to obtain the available members bound by the allocation rules, sort the available members according to the preset sorting field, and form an ordered attempt queue. The breakpoint location module is used to determine the starting position of this allocation attempt: if the allocation pointer maintained by the system exists, it starts from the first member in the attempt queue whose sort field value is greater than the value recorded by the allocation pointer; otherwise, it starts from the first member in the attempt queue; wherein, the allocation pointer records the sort field value corresponding to the member that was successfully allocated last time; The member-by-member allocation module is used to perform allocation attempts on each member in the attempt queue in sequence, starting from the initial attempt position, until the allocation is successful or the attempt queue has been traversed. The member-by-member allocation module includes a clue creation unit and a failure handling unit; The clue creation unit is used to perform a clue creation operation on the current member. When the creation is successful, it updates the allocated count of the current member and updates the allocation pointer to the sort field value of the current member, and ends the current allocation. The failure handling unit is used to write the form's identification information into the failure cache when creation fails, and continue to try the next member; wherein, the forms in the failure cache are allowed to be reassigned when the retry count has not reached the preset retry limit, and are removed from the waiting queue after the limit is reached.

[0012] In some embodiments, an electronic device includes: a processor, a memory, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the aforementioned Facebook inquiry auto-distribution method.

[0013] The Facebook inquiry auto-assignment method, system, and electronic device provided in this disclosure can achieve the following technical effects: Compared with the prior art, the embodiments disclosed herein have the following beneficial effects: By introducing a preset sorting field and maintaining an independent allocation pointer accordingly, the allocation progress information and member identity are completely decoupled. Even if a member at a recorded position is deleted, the system can still locate the correct subsequent position among existing members by comparing the numerical values ​​of the sorting field, ensuring the continuity of allocation order and the fairness of polling, and realizing automatic recovery under abnormal member changes. At the same time, by constructing a failure caching mechanism with a retry limit, when a clue creation fails, the form is written to the cache and the next member is tried. The failed form is allowed to be reassigned when the retry count has not reached the preset retry limit, and is removed from the waiting queue after reaching the preset retry limit, effectively curbing the consumption of system resources by infinite retries and forming an abnormal self-healing closed loop of "try-caching-limited retry-termination". The above-mentioned breakpoint recovery mechanism and failure caching mechanism work together in a unified allocation attempt loop. The former ensures reliable continuation of progress under abnormal member changes, and the latter ensures graceful convergence of the process under abnormal operation failures, fully covering the two most common core anomalies of polling allocation systems, and systematically improving the robustness of automated allocation operation.

[0014] The above general description and the description below are exemplary and explanatory only, and are not intended to limit the embodiments of this disclosure. Attached Figure Description

[0015] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a flowchart illustrating the automatic Facebook query allocation method provided in an embodiment of the present invention.

[0016] Figure 2 This is a schematic diagram of the structure of the Facebook inquiry auto-distribution device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0017] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0018] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0019] Unless otherwise stated, the term "multiple" means two or more.

[0020] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0021] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0022] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.

[0023] It should be noted that, in current technologies, some systems attempt to combine fixed quota allocation with a round-robin mechanism to improve the efficiency and conversion rate of Facebook inquiries. For example, some foreign trade CRM systems allow administrators to set a daily quota limit for each salesperson, and the system allocates quotas sequentially according to a preset order, automatically skipping the salesperson once the quota is used up. While this method can automate allocation to some extent, maintaining the allocation progress typically relies on recording the "last allocated member ID." When a member is deleted or deactivated due to resignation, job transfer, or other reasons, the system cannot find the corresponding record, resulting in a lost allocation breakpoint and forcing the allocation process to restart from the beginning, thus undermining the fairness of the round-robin mechanism.

[0024] With the growth of foreign trade, the number of Facebook inquiries has increased dramatically. During the allocation process, issues such as lead creation interface errors and data validation failures can lead to allocation failures. Existing solutions typically handle these failed forms by simply re-queuing or rolling back their status, resulting in failed forms being repeatedly tried in each allocation task. This endless retries continuously consume system computing resources and interface call quotas, generate a large number of duplicate error logs, and increase the operational burden.

[0025] In addition, some systems use scheduled tasks to trigger batch allocation, but in a multi-instance deployment environment, the same batch of unallocated forms may be processed by multiple task instances at the same time, resulting in the same form being repeatedly allocated to different salespersons, causing follow-up conflicts and data inconsistencies.

[0026] In summary, current technologies have laid a certain foundation in areas such as automatic inquiry allocation, polling scheduling, and quota management. However, these technologies primarily focus on the allocation logic implementation under normal scenarios. Existing polling allocation mechanisms suffer from systemic reliability flaws in automated operation under abnormal scenarios: the maintenance of allocation progress heavily relies on member identification, and the lack of self-healing and termination strategies in anomaly handling leads to system interruptions or ineffective retry loops in abnormal scenarios such as member deletion or lead creation failures, resulting in poor reliability of automated operation. Therefore, how to enable the allocation system to automatically recover and gracefully converge under the two core anomalies of member changes and operation failures remains a technical issue that requires further consideration in Facebook's automatic inquiry allocation.

[0027] It should be understood that the above description of the relevant technologies is intended only to help the public better understand the inventive spirit and motivation of this application, and is not intended to limit this application. Furthermore, the technical solutions described in the above-mentioned relevant technologies are not prior art, and may also be undisclosed technical solutions, such as those under research or in the laboratory stage.

[0028] Regarding the execution entity of the method in this application embodiment, it can be any controller or processor with computing or processing capabilities, such as the server of a foreign trade CRM system, which communicates with the Facebook advertising platform through a Webhook callback interface and is configured with Redis caching and a relational database. This server implements the method of this application embodiment by running programs or instructions stored in a storage medium. In some examples, it can be integrated into an electronic device or terminal through software, hardware, or a combination of both, and the type of terminal or electronic device can be diverse.

[0029] Figure 1 A flowchart illustrating an example of an automatic Facebook inquiry allocation method according to an embodiment of the present invention is shown. The automatic Facebook inquiry allocation method based on intelligent retention provided in this embodiment can be implemented in... Figure 2 The apparatus 200 shown includes: The form retrieval module 210 is used to communicate with the Webhook callback interface of the Facebook advertising platform, receive and store raw inquiry form data, and retrieve unassigned Facebook inquiry forms from the queue to be assigned via a scheduled task.

[0030] The member sorting module 220 is used to read available members bound by allocation rules from a relational database, sort the available members according to a preset sorting field, and form an ordered attempt queue. In one embodiment, the member sorting module 220 is also used to perform intelligent retention filtering and member grouping processing.

[0031] The breakpoint positioning module 230 is used to read the allocation pointer of persistent storage from the allocation rule configuration table and locate the starting position of this allocation in the attempt queue.

[0032] The member-by-member allocation module 240 is used to perform allocation attempts on each member in the attempt queue sequentially, starting from the initial attempt position. This module includes a thread creation unit and a failure handling unit. The thread creation unit is used to call the thread creation service, update the current member's allocation count and write the allocation pointer back to the allocation rule configuration table upon successful creation. The failure handling unit is used to write the form's identification information to the Redis failure cache and increment the retry count corresponding to that form when creation fails.

[0033] The failure recovery module 250 is used to periodically scan the failure records in the Redis failure cache, remove forms with retry counts that have reached the preset limit from the cache and mark them as manually processed, and add forms with retry counts that have not reached the limit back to the queue to be assigned.

[0034] The above modules work together in a unified allocation attempt loop: the form obtained by the form acquisition module 210 is preprocessed by the member sorting module 220 and the breakpoint positioning module 230, and then the member-by-member allocation attempt module 240 performs the allocation attempt; the failure cache records written by the failure handling unit are scanned and processed in the background by the failure recovery module 250, and the forms that meet the conditions are added back to the allocation queue for the form acquisition module 210 to acquire again, forming a complete allocation closed loop.

[0035] like Figure 1 As shown, in step S110, the form acquisition module 210 acquires the Facebook inquiry form to be assigned.

[0036] In this embodiment, after a user submits an advertising form, the Facebook advertising platform sends the form data to the Customer Relationship Management (CRM) system via a Webhook callback. The system receives and stores the raw form data through MetaFbLeadgenService. This form data includes basic information about potential customers, advertising source identifiers, submission time, etc.

[0037] To address the technical issue in multi-instance deployment environments where the same batch of unassigned forms may be processed simultaneously by multiple scheduled task instances, leading to duplicate assignment of the same form to different sales personnel and causing follow-up conflicts and data inconsistencies, one implementation step involves obtaining Facebook inquiry forms to be assigned through scheduled tasks. These scheduled tasks are hash-sharded based on ad identifiers, and each shard executes independently after acquiring a distributed lock, retrieving a preset batch size of forms each time. For example, for a system generating thousands of inquiries daily, the batch size can be set to 100, and the number of shards can be set to match the number of server instances. When the number of server instances changes, the number of shards is adjusted or the mapping relationship between shards and instances is reallocated to maintain a balanced number of unassigned forms across instances. Thus, through shard scheduling and a distributed lock mechanism, it is ensured that the same form will not be processed simultaneously by multiple task instances in a multi-instance deployment environment, eliminating the concurrency risk of duplicate assignment. The unassigned forms refer to those with an unassigned status and whose identifier information does not exist in the failure cache, to prevent failed forms from being repeatedly retrieved within the current period.

[0038] To illustrate the working principle of the sharding scheduling and distributed lock mechanism, a specific deployment scenario is used as an example. Assume a foreign trade CRM system is deployed with three server instances (Instance A, Instance B, and Instance C). Each day, forms to be assigned involve three advertising accounts (Ad IDs AD001, AD002, and AD003). When a scheduled task is triggered, each instance performs a hash calculation on the three advertising IDs: hash(AD001)%3=1, assigned to instance A; hash(AD002)%3=2, assigned to instance B; and hash(AD003)%3=0, assigned to instance C. Before processing forms for a given shard, each instance must acquire the corresponding distributed lock (e.g., a Redis lock with the key "DISTRIBUTION_LOCK:shard number"). After successfully acquiring the lock for shard 1, instance A begins processing forms under AD001. If instance A fails to complete processing before the lock timeout due to network latency, the lock is automatically released, and other instances can compete to acquire the shard lock in the next round of scheduled tasks. The distributed lock is configured with a preset timeout period, which is longer than the estimated maximum processing time for a single batch of forms. During normal processing, an instance can proactively release the lock after completing a single batch without waiting for the timeout, thus avoiding unnecessary waiting. Through this mechanism, forms under the same advertising account are always processed by a single instance holding the corresponding shard lock, fundamentally eliminating the possibility of the same form being allocated by multiple instances simultaneously.

[0039] In step S120, the member sorting module 220 obtains the available members bound by the allocation rules, sorts the available members according to the preset sorting field, and forms an ordered attempt queue.

[0040] In this embodiment, the system queries the allocation rules bound to the advertising account to which the current inquiry belongs, and then obtains all available members whose status is enabled under that rule. In a business scenario, these members typically correspond to salespersons of a foreign trade company, and each salesperson is responsible for following up on the inquiry leads assigned to them.

[0041] Each member has a preset sorting field. As one implementation, this sorting field is a globally incrementing sort number generated by a timestamp when the member is created. For example, the first member added to the allocation rule has a sort number of 1001, the second 1002, and so on. When a new member is added, its sort number is incremented based on the existing maximum value; when a member is deleted or deactivated, its corresponding sort number record is still retained in the historical data to enable subsequent breakpoint recovery. When a member is deactivated and then reactivated, its original sort number is retained to maintain the stability of the allocation order. The system sorts available members in ascending order according to this sorting field, forming an ordered attempt queue.

[0042] To address the technical problem in existing technologies that fail to consider the current follow-up load of salespersons, resulting in weaker salespersons accumulating a large number of leads while stronger salespersons are unable to allocate new leads, one implementation includes an intelligent retention filtering step after obtaining the available members bound to the allocation rules and before sorting the available members according to a preset sorting field. Specifically, the preset salesperson level (e.g., L0, L1, L2, L3) of each member is obtained, and the corresponding threshold for the number of unfollowed leads is read from the tenant-level configuration information based on the salesperson level. This configuration information can be stored in the tenant configuration table in JSON format, for example, `{"levelZeroThreshold":5, "levelOneThreshold":10, "levelTwoThreshold":20,"levelThreeThreshold":30}`. A batch query is performed to determine the total number of leads under each member whose status is unfollowed and not closed, which is taken as the current number of unfollowed leads for each member. Members whose current number of unfollowed leads is greater than or equal to the corresponding threshold for the number of unfollowed leads are removed from the set of available members.

[0043] The intelligent retention and filtering mechanism described above can dynamically filter overloaded members based on their salesperson level and the threshold for the number of unfollowed leads, preventing leads from piling up at one member's desk while other members remain idle, thus directing inquiries to members with follow-up capabilities, improving overall follow-up efficiency and allocation fairness.

[0044] To illustrate the working principle of the intelligent retention filtering mechanism, a specific example is provided below. Assume the current allocation rule binds three salespersons: Salesperson A (Level L2, 8 unfollowed leads), Salesperson B (Level L1, 10 unfollowed leads), and Salesperson C (Level L0, 4 unfollowed leads). The tenant's configured intelligent retention thresholds are: L0 threshold 5, L1 threshold 10, and L2 threshold 20. When the system executes intelligent retention filtering: Salesperson A, being Level L2, has 8 unfollowed leads, which is less than the L2 threshold of 20, and passes the filter; Salesperson B, being Level L1, has 10 unfollowed leads, which equals the L1 threshold of 10, and is removed; Salesperson C, being Level L0, has 4 unfollowed leads, which is less than the L0 threshold of 5, and passes the filter. Ultimately, the only available members for this allocation are Salesperson A and Salesperson C; Salesperson B is suspended from allocation due to severe lead backlog. Through this mechanism, the system automatically identifies and temporarily skips members who are overloaded, directing new inquiries to members who still have the capacity to follow up, thus avoiding the imbalance of distribution where "the busy get busier and the idle get idler."

[0045] To address the technical problem of existing technologies having a single allocation strategy that cannot simultaneously ensure quota fairness and allocation success rate within the same allocation process, one implementation includes member grouping after obtaining the available members bound to the allocation rules and before sorting them according to a preset sorting field. Specifically, available members are divided into a fixed quota group and an average allocation group according to allocation type. These two groups are sorted separately according to the sorting field and then merged into a final attempt queue, with the fixed quota group first and the average allocation group last. This grouping process ensures that members with fixed quotas are given priority in allocation tasks, and when their quotas are exhausted, they are automatically transferred to members with average allocation, thus achieving a balance between quota protection and comprehensive coverage without increasing process branches. When intelligent retention filtering and member grouping are used simultaneously, the intelligent retention filtering is performed first, followed by the grouping process on the filtered available members.

[0046] In step S130, the breakpoint location module 230 determines the starting position of the current allocation attempt based on the allocation pointer.

[0047] It is important to emphasize that this is one of the key steps that distinguishes this embodiment from the existing technology of "recording the last allocated member ID". In existing round-robin allocation schemes, the maintenance of allocation progress highly depends on member identity identifiers. When a recorded member is deleted, the breakpoint is lost, and the allocation process is forced to start from the beginning, compromising the fairness of the round-robin process. This embodiment maintains an independent allocation pointer, which records the sorting field value corresponding to the last successfully allocated member, rather than the member ID. Through this design, allocation progress information is recorded as a sorting field value, completely decoupling it from member identity identifiers. The allocation pointer is persistently stored in the allocation rule configuration table, ensuring that it can still be retrieved after a system restart.

[0048] To facilitate understanding of the fundamental difference between the breakpoint recovery mechanism based on the sorting field value and the existing "recording member ID" method, a comparative example is provided below. Assume the attempt queue contains three members with sorting numbers 1001, 1002, and 1003. After a successful allocation to member B (sorting number 1002), the allocation pointer record value is 1002. Under the existing "recording member ID" method: if member B is deleted, the system searches for member B's ID. Since the ID no longer exists, the breakpoint is lost, and allocation is forced to restart from the first member A (sorting number 1001) in the queue. This results in member A being repeatedly allocated, compromising the fairness of the round-robin process. Under the mechanism of this invention: the allocation pointer records the sorting field value 1002, not member B's ID. After member B is deleted, the system searches for members with a sorting field value greater than 1002 among existing members A (1001) and C (1003), finding member C (1003), and continues allocation from member C. The entire process requires no manual intervention, the continuity of the allocation order is maintained, and member A will not be reassigned due to the deletion of member B.

[0049] Specifically, the logic for determining the starting position in this step is as follows: If the allocation pointer exists, search the attempt queue for the first member whose sort field value is greater than the value recorded by the allocation pointer, and start the current allocation attempt from that member; otherwise, start from the first member of the attempt queue. If the allocation pointer exists, but no member with a sort field value greater than the value recorded by the pointer is found in the attempt queue (i.e., the member pointed to by the pointer is the member with the largest sort field value in the queue, and one round of polling has been completed), then fall into the "otherwise" branch, and start from the first member of the attempt queue to achieve polling loopback. If the allocation pointer does not exist (i.e., the system is running for the first time, and there are no successful allocation records yet), also start from the first member of the attempt queue.

[0050] To illustrate the fault tolerance of this mechanism more intuitively, we will now explain it in conjunction with the allocation pointer positioning process described above. When a member is deleted or deactivated, its corresponding sorting field value record still exists in the historical data, and the value recorded by the allocation pointer is precisely that sorting field value, and it will not be lost due to the expiration of the member's identity. For example, if a member with a sorting field value of 1002 is deleted, and the allocation pointer record value is 1002, the system can correctly locate the next member by searching for a member with a sorting field value greater than 1002 (such as 1003) among the existing members, without manual intervention. This ensures the continuity of the allocation order and the fairness of the round-robin process.

[0051] In step S140, the member-by-member allocation module 240 starts from the initial attempt position and performs allocation attempts on each member in the attempt queue in sequence until the allocation is successful or the attempt queue has been traversed.

[0052] Starting from the initial attempt position determined in step S130, allocation attempts are performed on each member sequentially according to the order of the attempt queue. The specific process of allocation attempts includes: the lead creation unit performs a lead creation operation on the current member; the lead creation operation includes: using the customer information in the form, the advertisement identifier to which the form belongs, the identifier of the current member, and the current timestamp as input parameters, calling the lead creation service to generate a new lead record; if the lead record is successfully generated and persisted to the database, it is considered a successful creation; if the lead record fails to be generated or persisted due to interface timeout, database write exception, or business rule verification failure, it is considered a failed creation; if the creation is successful, the allocated count of the current member is updated, and the allocation pointer is updated to the sorting field value of the current member, ending the current allocation. The updated allocation pointer will be used as the positioning basis for step S130 in the next allocation; if the creation fails, the failure handling unit writes the form's identifier information to the failure cache and continues to try the next member.

[0053] To address the technical problem in existing technologies where the lack of a closed-loop handling mechanism for failed form allocation leads to infinite retries of failed forms, continuously consuming system computing resources and API call quotas, this embodiment allows forms in the failure cache to be reassigned as long as the retry count has not reached a preset retry limit. Once the limit is reached, they are removed from the allocation queue. The allocation queue refers to the data set of forms to be allocated retrieved by the scheduled task each time it executes; it is the same concept as the allocation queue itself, both referring to the data structure storing forms that have not yet been successfully allocated and have not been moved to the manual processing state. The retry limit can be configured according to business needs, for example, set to 3 times. Through the above-described "write to cache upon failure, continue to the next member, terminate upon reaching the limit" processing method, a complete exception self-healing closed loop of "attempt-caching-limited retries-termination" is constructed, effectively curbing the infinite consumption of system resources by failed forms.

[0054] To illustrate the difference between the limited retry mechanism described above and the existing "unlimited retries" approach, a specific example is provided. Suppose a form fails to create due to a business rule validation error. The form is written to a failure cache with an initial retry count of 1. In two subsequent background scans, the form is re-added to the allocation queue and re-attempted for allocation, both failing for the same reason, with the retry count increasing to 2 and 3 respectively. When the retry count reaches the preset limit of 3, the form is removed from the failure cache and marked as "manual processing," automatically triggering an alarm to notify the administrator. Upon intervention, the administrator discovers an anomaly in the customer contact number format within the form, corrects it, and manually completes the allocation. In this process, the failed form is retried only a limited number of times and is not processed in an infinite loop. In contrast, existing technology, in the same scenario, would repeatedly queue and retry the form, continuously consuming system resources and generating numerous duplicate error logs until manual intervention is required.

[0055] To address the technical issue that a single failure might be caused by temporary factors such as network jitter, immediately writing to the cache and counting retry attempts could lead to unnecessary retry count consumption. One implementation writes the form's identification information to the failure cache and continues trying the next member. Specifically, this involves: determining whether the creation failure is a temporary error; if so, immediately retrying the current member a preset number of times (e.g., once); if the retry still fails, or the creation failure is not a temporary error, writing the form's identification information to the failure cache, incrementing the retry count for that form, and continuing to try the next member. By classifying the reasons for failure, immediate recovery opportunities are provided for temporary faults, reducing invalid cache writes and making the system's fault tolerance more refined and reasonable. When all members in the attempt queue have been traversed without successful allocation, the form's identification information is written to the failure cache, and its retry count is incremented, awaiting subsequent background scanning or manual intervention.

[0056] In this embodiment, the failure recovery module 250 also executes a background management task independent of the main allocation process. The failure recovery module 250 periodically (e.g., hourly) scans the failure records in the failure cache to obtain the retry count for each form. For forms with a retry count less than a preset upper limit, their status is reset to pending allocation. For forms with a retry count reaching the preset upper limit, they are removed from the failure cache, marked as "manual processing," and no longer participate in automatic allocation. Simultaneously, an alarm can be triggered to notify the administrator to intervene.

[0057] This backend management mechanism provides a clear final exit for failed forms. Forms are given a limited number of retries before being gracefully switched to manual processing. This avoids valuable inquiries being permanently buried due to occasional errors and prevents problematic forms from endlessly interfering with the automatic allocation system, achieving a reasonable balance between system automation and manual intervention. Each record in the failure cache has an independent expiration time, which is greater than the product of the preset retry limit and the backend scanning cycle, ensuring that cached records are not lost due to expiration before the form completes its limited number of retries.

[0058] To address the technical problem in existing technologies where high-value forms may be assigned to novice sales staff while low-value forms may be assigned to experienced sales staff, resulting in unreasonable resource utilization, one implementation method further includes, after obtaining the forms to be assigned in step S110, determining the form level (e.g., L0 to L3). The form level can be determined comprehensively based on factors such as advertising type, customer attributes, and historical conversion data. Simultaneously, in the assignment attempt in step S140, a level permission check step is added: obtaining the set of form levels that the current member is allowed to process; if the current form's form level is not within this set, the current member is skipped, and no further attempts are made in this round of assignment; the next member is then tried. This level permission matching mechanism ensures that high-value forms are preferentially assigned to experienced members with corresponding processing permissions, optimizing the allocation of sales resources and improving lead conversion rates. The set of form levels that each member is allowed to process is preset configuration information stored in a member configuration table.

[0059] To illustrate the effectiveness of the aforementioned level-based permission matching mechanism, a specific example is provided below. Assume the current form's level is determined to be L3 (high-value inquiry), and the attempt queue is as follows: Member A (allowed processing level set {L0, L1}), Member B (allowed processing level set {L2, L3}), and Member C (allowed processing level set {L0, L1, L2, L3}). The system performs level-based permission checks sequentially: Member A's allowed processing level set is {L0, L1}, and the current form's level L3 is not within this set, so permission is insufficient, and Member A is skipped; Member B's allowed processing level set is {L2, L3}, and the current form's level L3 is within this set, so permission matches, and subsequent lead creation operations are executed. Thus, the high-value L3 form is prevented from being assigned to Member A, who only has low-level processing permissions, and is instead preferentially assigned to Member B, who has the corresponding permissions. This ensures that high-value leads are followed up by salespeople with the appropriate capabilities, improving lead conversion rates.

[0060] In another implementation, when member grouping is used in step S120, a quota check step is added to the allocation attempt in step S140: if the current member belongs to a fixed quota group and its allocated quantity for the day has reached the preset daily quota limit, then the current member is skipped and the next member is tried. This allows quota management to be seamlessly embedded into the member-by-member check of the main allocation loop, resulting in high execution efficiency and reduced error.

[0061] To facilitate understanding of the quota checking and automatic switching process in the above hybrid allocation strategy, a specific round example is provided below. Assume the attempt queue consists of: Member A (fixed quota, 18 allocated today, quota limit 20), Member B (fixed quota, 20 allocated today, quota limit 20), and Member C (average allocation, no quota limit). When the current form begins its allocation attempt, Member A is checked first: it belongs to the fixed quota group, and its allocated quota of 18 is less than the quota limit of 20, thus passing the quota check. Subsequent level permission checks and lead creation are then performed. When a subsequent form reaches Member A again, its allocated quota has reached 20, so the quota check fails, and the system skips Member A and continues checking Member B. Member B's allocated quota of 20 equals the quota limit of 20, so it is also skipped. The system then checks Member C, who belongs to the average allocation group and has no quota limit, so it passes directly. Therefore, once a member with a fixed quota has exhausted their quota, the allocation task is seamlessly transferred to a member with an average allocation, without the need for the administrator to manually adjust or wait for the quota to reset the next day, thus achieving an automatic balance between quota protection and allocation continuity.

[0062] The following example, using a typical exception scenario, illustrates the synergistic effect of the breakpoint recovery mechanism and the failure caching mechanism in the unified allocation loop of this embodiment: Suppose the current allocation rule binds member A (sort number 1001), member B (sort number 1002), and member C (sort number 1003). When an allocation task is triggered, the allocation pointer record value is 1001, so it starts from member B (whose value is greater than 1001). Member B successfully creates a lead, and the pointer is updated to 1002. Later, member B is deleted from the system by the administrator due to resignation.

[0063] When the next allocation task is triggered, the allocation pointer record value will still be 1002. The system searches for members with a sort field value greater than 1002 among the existing members (A and C), finds member C (1003), and starts allocation from member C. If member C fails to create a thread (e.g., interface timeout), the system determines that the failure is a temporary error and immediately retryes member C a preset number of times; if the retry still fails, the system writes the form to the failure cache, increments the retry count, and continues to try member A. If member A is created successfully, the pointer is updated to 1001, and this round of allocation ends. In subsequent timed scans, if the number of retries has not reached the limit, the failure form will be added back to the allocation queue; if the limit is reached, it will be removed from the cache and the administrator will be notified.

[0064] In the above scenario, the breakpoint recovery mechanism solves the progress interruption problem caused by "member B being deleted", and the failure caching mechanism solves the infinite loop problem caused by "member C failing to be created". The two work together in the same allocation loop, fully covering the two core exceptions of "member change" and "operation failure", and realize automatic recovery without manual intervention.

[0065] In the aforementioned complex exception scenarios, the breakpoint recovery mechanism resolves the progress interruption caused by "member identity change," allowing allocation to continue from the correct position; the failure caching mechanism resolves the infinite loop problem caused by "operation failure," providing a clear termination point for the failure form after limited retries. The synergistic significance of both in the same allocation loop lies in the following: if only breakpoint recovery exists without failure caching, the system can continue allocation after a member is deleted, but will get stuck in infinite retries for that member if creation fails; if only failure caching exists without breakpoint recovery, the failure form can be cached and retried with limited retries, but the breakpoint is lost after a member is deleted, leading to out-of-order allocation. Only by combining both can the system fully cover the two most common core exceptions, "member change" and "operation failure," achieving automatic recovery without manual intervention.

[0066] Figure 2 A structural block diagram of an example of a Facebook inquiry auto-distribution device according to an embodiment of this application is shown. Figure 2 As shown, the Facebook inquiry auto-assignment device 200 includes a form acquisition module 210, a member sorting module 220, a breakpoint location module 230, and a member-by-member attempt assignment module 240.

[0067] The correspondence between the modules in the aforementioned device 200 and the method steps of this embodiment is as follows: the form acquisition module 210 executes step S110, the member sorting module 220 executes step S120, the breakpoint location module 230 executes step S130, the member-by-member allocation attempt module 240 executes step S140, and the failure recovery module 250 executes a background management task independent of the main allocation process. The specific process of the collaborative work of each module has been described in the method description of this embodiment in conjunction with the application scenario, and will not be repeated here.

[0068] In some embodiments, the member-by-member allocation module 240 includes a lead creation unit and a failure handling unit. The lead creation unit performs a lead creation operation on the current member, updates the allocated count of the current member upon successful creation, updates the allocation pointer to the sorting field value of the current member, and ends the current allocation. The failure handling unit, upon failure, writes the form's identification information into a failure cache and continues to try the next member; wherein, forms in the failure cache are allowed to be reassigned as long as the retry count has not reached a preset retry limit, and are removed from the allocation queue after reaching the limit. In one embodiment, the failure handling unit is specifically used to: determine whether the creation failure is a temporary error; if so, immediately retry the current member a preset number of times; if the retry still fails, or the creation failure is a non-temporary error, write the form's identification information into the failure cache, increment the retry count corresponding to the form, and continue to try the next member.

[0069] In one embodiment, the device further includes a failure recovery module 250, which is used to periodically scan the failure records in the failure cache to obtain the retry count corresponding to each form; if the retry count is less than the preset retry limit, the corresponding form is added back to the allocation queue; if the retry count reaches the preset retry limit, the corresponding form is removed from the failure cache, marked as manual processing status, and no longer automatically allocated.

[0070] To illustrate how the modules work together to form the complete allocation anomaly self-healing system described in this invention, a workflow example spanning all modules is presented below. At a certain moment, the form acquisition module 210 securely retrieves a batch of forms to be allocated from Redis using sharding scheduling and distributed lock mechanisms, and passes one of these forms to the downstream module. Upon receiving the allocation request, the member sorting module 220 reads all online members under the allocation rules corresponding to the advertising account from the database, filters out overloaded members whose number of unfollowed leads exceeds the threshold, groups the remaining members by allocation type and arranges them in ascending order by sorting number, forming an ordered attempt queue that is passed to the breakpoint location module 230. The breakpoint location module 230 reads the persistently stored allocation pointer value from the allocation rule configuration table, locates the starting member position in the attempt queue, and passes the starting index to the member-by-member attempt allocation module 240. The member-by-member allocation module 240 traverses the attempt queue starting from the initial index: for each member, the lead creation unit calls the lead creation service to attempt to generate a lead record; if successful, it updates the member count and writes the new allocation pointer value back to the allocation rule configuration table; if it fails, the failure handling unit writes the failure form information to the Redis failure cache and increments the retry count. When the failure retry count of a form reaches the upper limit, the failure recovery module 250 removes it from the cache and marks it for manual handling during a background periodic scan. The above modules work together in a unified allocation attempt loop to automatically cover and self-heal the two core exceptions of "member change" and "operation failure".

[0071] In some embodiments, this application provides a non-volatile computer-readable storage medium storing one or more programs including execution instructions, which can be read and executed by electronic devices (including but not limited to computers, servers, or network devices) to perform the steps of any of the Facebook query automatic allocation methods described above.

[0072] In some embodiments, this application also provides a computer program product, the computer program product including a computer program stored on a non-volatile computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the steps of any of the above-described Facebook inquiry automatic allocation methods.

[0073] In some embodiments, such as Figure 3 As shown, combined with Figure 3As shown, this disclosure also provides a content generation electronic device, including a processor 300 and a memory 301. Optionally, the device may further include a communication interface 302 and a bus 303. The processor 300, communication interface 302, and memory 301 can communicate with each other via the bus 303. The communication interface 302 can be used for information transmission. The processor 300 can call logical instructions in the memory 301 to execute the content generation method of the above embodiments.

[0074] Furthermore, the logic instructions in the aforementioned memory 301 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0075] The memory 301, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 300 executes functional applications and data processing by running the program instructions / modules stored in the memory 301, that is, it implements the content generation method in the above embodiments.

[0076] The memory 301 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 301 may include high-speed random access memory and may also include non-volatile memory.

[0077] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0078] The electronic devices in this application can exist in various forms, including but not limited to: mobile communication devices, ultra-mobile personal computer devices, portable entertainment devices, or other airborne electronic devices with data interaction functions.

[0079] The Facebook inquiry automatic assignment method, apparatus, and related equipment (including computer-readable storage media, computer program products, and electronic devices) provided in this application can produce at least the following technical effects: By introducing a predefined sorting field and maintaining an independent allocation pointer accordingly, allocation progress information is completely decoupled from member identification. Even if a member whose original position is recorded is permanently deleted, the system can accurately locate the correct subsequent position among existing members simply by comparing the values ​​of the sorting field, ensuring the continuity of the allocation order and the fairness of the polling, and automatically recovering from anomalies without manual intervention.

[0080] By constructing a failure cache with a retry limit and a self-healing loop, when a lead creation fails, the form is not retried indefinitely. Instead, it is written to the failure cache and its retry count is incremented, while other available members are still being tried. Forms that have not reached the retry limit are allowed to be reassigned, giving queries that failed due to temporary faults a second chance; forms that have reached the retry limit are gracefully removed from the allocation queue and transferred to manual processing. This mechanism effectively curbs the unlimited consumption of system resources by failed forms, forming a complete exception self-healing loop of "attempt-caching-limited retries-reassignment / termination".

[0081] "Independent pointer breakpoint recovery based on sorting field" and "failure cache self-healing with retry limit" are not two isolated improvements, but rather work synergistically within a unified allocation attempt loop, forming a complete allocation exception self-healing system. The former ensures reliable continuation of allocation progress under member change exceptions, while the latter ensures graceful convergence of the allocation process under operation failure exceptions. Together, they fully cover the two most common core exceptions in polling allocation systems, systematically improving the robustness of automated allocation operation.

[0082] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0083] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0084] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

Claims

1. A method for automatically assigning Facebook inquiries, characterized in that, include: Retrieve Facebook inquiry forms to be assigned; Obtain the available members bound by the allocation rules, sort the available members according to the preset sorting field, and form an ordered attempt queue; Determine the starting position for this allocation attempt: if the allocation pointer maintained by the system exists, start from the first member in the attempt queue whose sort field value is greater than the value recorded by the allocation pointer; otherwise, start from the first member in the attempt queue; wherein, the allocation pointer records the sort field value corresponding to the member that was successfully allocated last time; Starting from the initial attempt position, each member in the attempt queue is assigned in sequence until the assignment is successful or the attempt queue has been traversed. The allocation attempt includes: performing a clue creation operation on the current member; if the creation is successful, updating the current member's allocated count and updating the allocation pointer to the current member's sort field value, ending the current allocation; if the creation fails, writing the form's identification information into the failure cache and continuing to try the next member; wherein, the forms in the failure cache are allowed to be reassigned when the retry count has not reached the preset retry limit, and are removed from the allocation queue after reaching the limit.

2. The method according to claim 1, characterized in that, Sort the available members according to a preset sorting field, including: When creating a member, a globally incrementing sort number is generated for each member based on the timestamp, and the available members are sorted using the sort number as the sorting field.

3. The method according to claim 1, characterized in that, Write the form's identification information to the failure cache and continue trying the next member, including: Determine if the creation failure is a temporary error; if so, immediately retry the current member a preset number of times. If the retry still fails, or the failure to create the form is a non-temporary error, the form's identification information is written to the failure cache, the retry count for the form is incremented, and the next member is tried.

4. The method according to claim 3, characterized in that, Also includes: Periodically scan the failure records in the failure cache to obtain the retry count for each form; If the retry count is less than the preset maximum number of retry attempts, the status of the corresponding form will be reset to the pending allocation status. If the retry count reaches the preset maximum number of retry attempts, the corresponding form will be removed from the failure cache, marked as manual processing status, and will no longer be automatically assigned.

5. The method according to claim 1, characterized in that, Retrieve the Facebook inquiry forms to be assigned, including: Facebook inquiry forms to be assigned are obtained through a scheduled task. The scheduled task is hashed and sharded according to the ad identifier. Each shard is executed independently after acquiring a distributed lock. Each execution retrieves a preset batch of forms.

6. The method according to claim 1, characterized in that, After obtaining the available members bound by the allocation rules, and before sorting the available members according to a preset sorting field, the process further includes: Obtain the preset salesperson level for each member, and read the corresponding threshold for the number of unfollowed leads from the tenant configuration information based on the salesperson level; Get the number of currently unfollowed leads for each member; Remove members whose current number of unfollowed leads is greater than or equal to the corresponding threshold for the number of unfollowed leads from the available members.

7. The method according to claim 6, characterized in that, Get the number of currently unfollowed leads for each member, including: Batch query the total number of leads under the available member name that are in a state of not being followed up and not closed, and use this as the current number of unfollowed leads for each member.

8. The method according to claim 1, characterized in that, After obtaining the available members bound by the allocation rules, and before sorting the available members according to a preset sorting field, the process further includes: The available members are divided into a fixed quota group and an average allocation group according to the allocation type, and then sorted and merged into the attempt queue. The allocation attempt also includes: if the current member belongs to a fixed quota group and the number of quotas allocated to it for the day has reached the preset daily quota limit, then skip the current member and continue to the next member.

9. A Facebook inquiry auto-distribution device, characterized in that, include: The form retrieval module is used to retrieve Facebook inquiry forms to be assigned. The member sorting module is used to obtain the available members bound by the allocation rules, sort the available members according to the preset sorting field, and form an ordered attempt queue. The breakpoint location module is used to determine the starting position of this allocation attempt: if the allocation pointer maintained by the system exists, it starts from the first member in the attempt queue whose sort field value is greater than the value recorded by the allocation pointer; otherwise, it starts from the first member in the attempt queue; wherein, the allocation pointer records the sort field value corresponding to the member that was successfully allocated last time; The member-by-member allocation module is used to perform allocation attempts on each member in the attempt queue in sequence, starting from the initial attempt position, until the allocation is successful or the attempt queue has been traversed. The member-by-member allocation module includes a clue creation unit and a failure handling unit; The clue creation unit is used to perform a clue creation operation on the current member. When the creation is successful, it updates the allocated count of the current member and updates the allocation pointer to the sort field value of the current member, and ends the current allocation. The failure handling unit is used to write the form's identification information into the failure cache when creation fails, and continue to try the next member; wherein, the forms in the failure cache are allowed to be reassigned when the retry count has not reached the preset retry limit, and are removed from the waiting queue after the limit is reached.

10. An electronic device, comprising: A processor, a memory, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the Facebook query auto-distribution method as described in any one of claims 1 to 9.

Images