A multi-dimensional attribution method and system for competition results based on structured competition data

Abstract

This invention discloses a multi-dimensional attribution method and system for competition results based on structured competition data. The method includes: a profile field template configuration step, generating a profile field template containing several profile field definitions, each definition including a field key, value range, and purpose identifier; a multi-path redundancy writing and consistency resolution step, reading profile field values ​​from the user master file in each registration writing path, redundantly writing according to the template to form a profile snapshot, checking for duplicates and idempotency according to a preset unique key, and pre-allocating memory for derived identifiers according to unit number segments and handling conflict continuation; an organizational structure tree attribution step, using competition business records as leaf nodes, converting competition results into group scores for each organizational node according to the organizational structure tree and aggregating them level by level, generating a multi-view leaderboard by gender dimension; post-event changes to the user master profile profile do not retroactively rewrite the profile snapshot, and historical attribution is based on the profile at the time of competition. This invention achieves consistency in competition data collection, governance, and attribution.

Description

Technical Field

[0001] This invention relates to the fields of data processing and sports event management technology, specifically to a multi-dimensional attribution method and system for event results based on structured participant data. It can be applied to scenarios such as school sports meets, single-sport events, and ball leagues where participants' results need to be reliably attributed by dimensions such as unit and gender and presented in multiple views. Background Technology

[0002] As the scale of campus sports events expands, the sources and entry points for participant data are becoming increasingly diverse. A typical event management system simultaneously handles functions such as student and faculty user profiles, individual / group registration, registration review and import, number arrangement, score entry, scorebook export, team rankings, and college points statistics. In actual development and operation, the inventors discovered the following common technical problems in the entire process of participant data flow.

[0003] (i) Inconsistent and inconsistent profile information for the same participant. Profile fields such as identity, gender, and college / organization for the same participant exist in the user master file and are also redundantly entered into the registration record. Different competitions and projects have different requirements for profile fields (such as age group, identity tags, and custom extended fields). The traditional approach is to hardcode the registration form fields into the code. Adding or cutting a data collection field requires modifying the front-end page and back-end interface and redeploying. At the same time, there are multiple equivalent ways to write the name of the participating unit, such as "full name - abbreviation - unit code". When directly matching strings to attribute results, different ways of writing the same unit will lead to inconsistent attribution results.

[0004] (ii) The anchor point for performance attribution drifts as the user profile changes. If the performance attribution dynamically references the current unit field in the user profile during query / calculation, then if a participant transfers, moves, or changes their identity between two competitions, their historical performance will be attributed to the new unit, causing the attribution of historical performance records and past rankings to drift, thus undermining the consistency and traceability of historical data.

[0005] (iii) Lack of consistency guarantee for multi-path writing. A single registration data can be written to the same data table through multiple paths such as self-registration by participants, group registration, registration by administrators, batch import, and waiting list. If each path implements its own writing logic and allocation logic for derived identifiers such as bib numbers, the following problems may easily occur: in batch scenarios, querying the database for the current maximum number one by one will cause response timeouts; in concurrent scenarios, numbers will be repeatedly allocated; duplicate registrations and registrations exceeding the limit will be bypassed due to inconsistent verification methods at different entry points.

[0006] (iv) The implementation of the attribution and multi-view ranking list is disconnected from the actual organizational structure, and the cache consistency is poor. The conversion logic from ranking to points and from individual scores to team scores is scattered in hard-coded; the same score needs to be fully aggregated once for each of the multiple dimensions such as "total team / men's team / women's team", and the calculation cost increases with the scale of the competition; after the scores are revised multiple times (published, returned, cleared, manually adjusted), if the ranking list cache does not become invalid and recalculated, it will present outdated results for a long time.

[0007] Therefore, there is an urgent need in this field for a method and system that unifies the governance of competition data in a structured and configurable manner across the entire chain from "collection, writing, attribution to querying," enabling profile fields to be configured as needed according to the competition, historical attribution to the competition time point, consistency in writing across multiple paths, and reliable attribution of results according to the actual organizational structure and multiple perspectives. Figure 1 Presented. Summary of the Invention

[0008] To address the aforementioned technical problems, this invention provides a multidimensional attribution method for competition results based on structured competition data, comprising the following contents.

[0009] Profile field template configuration steps: In response to a configuration request for a target event, a profile field template for the target event is generated and stored. During the registration phase, the profile field template is instantiated as a data structure constraint for the competition's business data. The profile field template contains several profile field definitions, each of which includes at least a field key, a value range, and a purpose identifier. The purpose identifier indicates at least one purpose of the profile field in registration data collection, rule matching, and performance attribution. The profile field template drives the collection of competition business data, enabling different profile field sets to be used as needed for different events or different projects within the same event. Multi-path Redundancy Write and Consistency Resolution Steps: Receive participation requests submitted via at least two registration write paths. In each registration write path, read the current profile field value from the participant's user profile and redundantly write it into the corresponding participation business record according to the profile field template, forming a profile snapshot in the participation business record. Perform consistency resolution on duplicate participation requests or conflicting writes generated during the writing process of multiple registration write paths: perform deduplication and idempotency processing on participation business records for the same event, the same participant, and the same project using a preset unique key; pre-allocate derived identifiers in memory according to the number range of the participant's affiliated organization and defer conflict accordingly when necessary; when the profile field in the user profile changes afterward, do not retroactively rewrite the generated profile snapshot, ensuring that historical attribution is based on the profile at the time of participation. Organizational structure tree attribution steps: Using the participating business record as the attribution leaf node, the participation score is converted into group points for each level of organizational node according to the pre-established organizational structure tree. The organizational structure tree contains at least a multi-level node relationship of "participating unit - subordinate organizational level - participating member". Each participating business record is associated with the corresponding node in the organizational structure tree through the organizational level field of the unit to which it belongs in its profile snapshot. The converted group points are aggregated level by level along the organizational structure tree, and multiple view lists are generated according to at least the gender dimension.

[0010] Furthermore, the method also includes the following preferred embodiments: The profile field definition also includes a data collection source and a snapshot strategy; the data collection source includes at least one of automatic reading from the user profile and manual filling in on the registration interface; the snapshot strategy is used to indicate whether the profile field value is frozen after being written into the competition business record; after the profile field template is generated, the registration interface dynamically renders the profile collection form items according to the template, and the server performs whitelist verification on the profile fields in the registration request according to the template. Profile fields outside the template are discarded to prevent bypassing the front-end interface and directly injecting additional data. The configuration data for the target event also includes number arrangement configuration, including an enable switch, the starting number and step size for each participating unit; when the derived identifier is a bib number, the candidate number is "the current maximum allocated number of the participating member's unit + step size", and if the candidate number has been occupied by another unit, it is extended by the step size; in the batch write scenario, the allocated number set of the event is pre-fetched into memory in a paginated manner, and the number pre-allocation is completed in memory and the position is occupied in real time, without querying the database one by one; The multiple registration paths include at least two of the following: self-registration by participating members, group registration, registration by administrators, batch import, and waiting list / submission. On each path, a unified check of participation constraints related to the event configuration (maximum number of participants from the same unit for the same project, limited number of projects to be registered, mutually exclusive project group constraints, etc.) is performed. For records in the waiting list / submission path that transition from waiting list status to official status, if a derived identifier has not yet been generated, the same derived identifier allocation logic as the other paths is invoked to generate it. For records in the existing competition business records that are missing portrait snapshots, the portrait snapshots are read in batches according to a preset batch size through a backfill interface and then written back idempotently. Records that already have portrait snapshots are skipped. Attribution is performed by reading attribution parameters from the event configuration data. These parameters include a ranking points table, a doubling factor, and a team splitting strategy. Individual scores are obtained by querying the ranking points table based on ranking and are recorded in the organizational node corresponding to the participating unit. Team scores are split into unit-level scores according to the team splitting strategy and are recorded in the respective units of each member. The scores of the same member are only accumulated once in their respective organizational nodes. The leaderboards of multiple views share the same intermediate results of node integrals calculated along the organizational structure tree. Each view generates the leaderboard by filtering and sorting the intermediate results according to its own view dimension. When multiple organizational node integrals are the same, they are ranked in the same place. The leaderboards of multiple views are stored in the form of an aggregate cache. When any of the following changes occur in the competition results: publication, rejection, clearing, or manual adjustment, the affected aggregate cache is cleared and then recalculated: first, the primary keys of all records to be cleared are retrieved page by page according to the clearing conditions and deleted in batches, and then the records are re-aggregated and written according to the changed competition results. Redundant backups of the aggregate cache are deduplicated according to the content summary, and only the most recent preset number of backups are retained. Receive query requests with query dimensions, locate and aggregate along the organizational structure tree, and return the scores or points under that dimension; when querying by participant, only return the results of that participant or those who are authorized to view them; When receiving a management request for a specified event, the system determines whether the operator has management authority based on the event affiliation. The event affiliation includes system administrators managing all events, event administrators managing assigned events or events created by themselves, and event creators managing events created by themselves. If the operator has management authority, attribution and aggregate cache invalidation recalculation are allowed; otherwise, the corresponding operation is rejected.

[0011] This invention also provides a multi-dimensional attribution system for competition results based on structured competition data, including a profile field configuration module, a multi-path redundant writing module, a multi-view aggregation and caching module, a result attribution module, and a query positioning module. Each module is used to implement the corresponding steps in the above method.

[0012] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the steps of any of the above methods.

[0013] The beneficial effects of this invention are as follows.

[0014] 1. Profile field template defined once and driven throughout the entire process: The same profile field template simultaneously drives the dynamic rendering and data collection of the registration interface and the server-side whitelist verification and database entry. The entire lifecycle of the profile field, from "collection to snapshot to freeze to backfill to attribution", is linked by the same structured definition. Different events and different projects within the same event can enable subsets of fields as needed, and expanding the collection dimensions does not require modification of the front-end and back-end code.

[0015] 2. Historical Attribution Anchored to the Competition Time: At the moment of registration, the user's master profile is redundantly snapshotted according to the template and frozen. Subsequent changes to the user's master profile will not retroactively rewrite the snapshot, thus eliminating the "historical performance attribution drift after transfer / relocation" from a mechanism perspective; existing missing snapshots can be converged through batch idempotent backfilling, supporting the migration of historical data.

[0016] 3. Multi-path write without duplication or omission: Constraint verification of unique key idempotency and consistency across all entry points prevents duplicate registrations and over-limit bypass; Derived identifiers such as bib numbers share an allocator with "prefetch full quantity + memory placeholder + conflict postponement" across multiple entry points, ensuring uniqueness within the event and avoiding timeouts and duplicate allocations caused by querying the database one by one in batch scenarios.

[0017] 4. One-time attribution, multiple view presentation: The results are attributed to the organizational structure tree to obtain the intermediate results of the node integrals. The overall ranking and the gender ranking and other views share the intermediate results and are derived by dimension, avoiding the repeated full aggregation of the same results and ensuring that the caliber of each view is consistent.

[0018] 5. Consistent caching and data change loop: Aggregated results are stored in the cache. The release / return / clearing / manual adjustment of scores triggers invalidation and recalculation according to the "clear first, write later" principle. Backup snapshots are deduplicated according to content summaries and retained in limited quantities. The ranking results are always consistent with the score data and the storage is controllable.

[0019] 6. Verified through actual deployment: Using an athletics meet with 31 events and three leaderboards (overall, men's, and women's) as the verification scenario, the verification process included: collecting snapshots of participating unit profiles; uniquely assigning bib numbers to 5 registration paths (automatic bib number assignments for 48 athletes across 4 participating units with no duplicates); verifying the accuracy of the overall team, men's team, and women's team scores after attribution by organizational structure tree; and ensuring consistent refresh of leaderboard caches after score corrections. No business code needed to be modified during the verification process.

[0020] The accompanying drawings of this invention are described below.

[0021] Figure 1 is a schematic diagram of the overall architecture of the multidimensional attribution system for competition results of the present invention; Figure 2 is a flowchart of the portrait field template configuration and registration data collection process of this invention; Figure 3 is a flowchart of the multi-path registration writing and consistency resolution process of the present invention; Figure 4 is a schematic diagram of the organization structure tree attribution and multi-view leaderboard generation of the present invention; Figure 5 is a flowchart of the aggregate cache invalidation and recalculation process of the present invention.

[0022] In Figure 1, the profile field configuration module, multi-path redundancy writing module, grade attribution module, multi-view aggregation and caching module, and query positioning module correspond to the five system modules of this invention; the step numbers in Figures 2 to 5 correspond to the step sequence of the corresponding embodiments in the specific implementation methods.

[0023] The specific embodiments of the present invention are as follows.

[0024] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings. These embodiments are for illustrative purposes only and should not be construed as limiting the scope of the invention.

[0025] The system of this invention adopts a two-layer architecture of "front-end mini-program + cloud function back-end (BaaS) + cloud database". The cloud database has a hard limit on the amount of data in a single read / write operation (a single query can return a maximum of 100 records, a single update / delete can affect a maximum of 1000 records, and a single batch conditional query can affect a maximum of 100 key-value pairs). Therefore, the system uniformly encapsulates operations that span multiple records into tools such as paginated reading, batch writing, and retrieving the full primary key before batch deletion. Embodiments 3 and 7 will demonstrate how these constraints affect the implementation of derived identifier allocation and aggregate cache cleanup.

[0026] The competition data within the system is stored in a structured format across multiple datasets: user profiles (users), individual registrations (signups), team registrations (team_signups), scores (results), and aggregate caches (rankings, college_score_rankings), etc. The fields and functions cited in the examples below are all derived from the above datasets and their corresponding cloud function implementations.

[0027] Example 1: Configuration of Portrait Field Template As shown in Figure 2, when operators configure a target event on the event creation page, the system generates a profile field template for that event. The profile field definitions in the profile field template are derived from a reusable profile field registry (frontend modules such as sport-features.js). Each field definition includes a field key, display label, data type, default value, partition, and purpose identifier (registration collection / rule matching / score attribution).

[0028] Taking a sports meet as an example, the profile fields that can be enabled in the event configuration include: gender, identity tags (student / teacher / staff / international / alumni, etc.), grade, age group (A / B / C, controlled by the staff age grouping switch staffAgeGroups), participating unit (college / unit), and custom extended fields (such as clothing size, supporting documents, etc.). The profile field template data structure is shown below: { "signupFields": { "gender": true, "ageGroup": true, "identityTag":true}, "identityTagOptions": ["student", "teacher", "staff"], "staffAgeGroups": { "enabled": true, "groups": ["A", "B", "C"]}, "customFields": { "key": "jerseySize", "label": "clothing size", "type": "select", "options": ["S", "M", "L", "XL"], "purpose": ["collect"]} } As shown in Figure 1, the configuration page (event-admin / config) reads the registry and renders the configuration form according to the field definitions. After the operation staff saves the configuration, the configuration is written into the event configuration document. The registration page (signup) reads the event configuration and dynamically renders the profile collection form items according to the template - when the age group switch is turned on, the age group drop-down is displayed, and when custom fields are configured, the corresponding input items are dynamically rendered. The server performs whitelist verification based on the profile field template at the write points of registration, draft, and update, and only accepts the profile fields defined in the template. All profile fields outside the template are discarded to prevent bypassing the front-end interface to directly inject additional data.

[0029] Different events within the same competition can enable different subsets of profile fields. For example, in a sports meeting, events for students need to collect gender and group participants by gender, while events for teaching and administrative staff need to collect age groups and group participants by age group. Different events present different sets of profile collection form items during registration, and the template itself can be reused by different event instances, and only the field value domain needs to be overwritten to adapt to a new event.

[0030] Second Embodiment: Multi-path Registration Writing and Profile Snapshot As shown in Figure 3, a piece of individual registration data can be written into the registration set through paths such as participant self-submission, group registration (team formation), administrator proxy registration, batch import, and alternate replacement. At the write point of each write path, the system does not only save the registration action itself, but also reads the current profile field values of the participating member from the user master file, and redundantly writes them into the registration record according to the event profile field template to form a profile snapshot.

[0031] ​Taking self-service registration (submit) as an example: The system reads the college code / college name of the participating members from the users master file and writes it into the registration record along with their name, gender, etc. At the same time, it appends user snapshot fields (such as gender, education level, user type) to the registration record for subsequent ranking and attribution, avoiding the need to check the master file again during ranking. The legitimacy of the organization is verified according to the list of participating organizations configured in the event. In non-administrator / forced submission scenarios, the organization name in the registration record must fall into the list of participating organizations in the event, preventing attribution errors caused by "synonyms / bypassing dropdown boxes" from the source.

[0032] The profile snapshot adopts a write-and-freeze strategy: if fields such as college and identity in the user's master file change afterward (such as student transfer, faculty transfer, or identity tag adjustment), the system will not retroactively rewrite the already generated registration snapshot. The attribution of historical results is based solely on the profile snapshot at the time of the competition, thereby ensuring the stability and non-drift of the attribution of previous year's scorebooks and historical rankings.

[0033] Example 3: Multi-path allocation of number derivation identifiers As shown in Figure 3, the bib number is a derived identifier used to uniquely identify participants within the event scope. The bib number allocation configuration in the event setup includes an enable / disable switch, the starting number for each participating unit, and the step size. This system provides two algorithms for bib number allocation: single-query and memory pre-allocation. Single-entry query: When assigning a number to a single registration, query the record with the status "passed and assigned number" under the unit to which the participant belongs, and use "maximum number + step size" as the candidate number; if the candidate number has been taken by another unit, retry according to the step size to ensure that the number is unique in the competition.

[0034] Memory pre-allocation: In batch write scenarios (batch approval of all numbers, batch import, batch replacement of candidates), the entire set of allocated numbers for the event is first pre-fetched into memory in pages, creating a "used numbers" set. Then, for each record to be allocated, the first unused number is searched in memory from the starting point of the unit's number segment, and immediately placed in the memory set after allocation. The entire allocation process avoids querying the database line by line, thus preventing issues like "timeouts for line-by-line database queries and duplicate allocations due to concurrent omissions" in large-scale scenarios.

[0035] The five registration writing paths (single approval, batch approval, batch import of registrations, waiting list supplementation, and manual number adjustment) share the above allocation logic: single approval skips records with already allocated numbers (idempotent, no duplicate allocation); batch approval and batch import use memory pre-allocation; for records that have changed from waiting list to official status, if no numbers have been allocated, the same allocation logic is called to generate numbers and rearrange the order of the remaining waiting lists; manual number adjustment performs a separate check for conflicts within the event.

[0036] Actual deployment verification: In the sports meet scenario, with 4 participating units and 48 athletes as samples, the bib numbers were automatically allocated through multiple paths such as approval and batch import. All numbers were unique and fell within the number range of each unit (starting number = unit code × 100).

[0037] Example 4: Batch Idempotent Backfilling of Existing Portrait Snapshots For historical team registration records that lack profile snapshots (e.g., early versions of team registration data did not have redundant unit snapshots), the system provides a backfilling interface: it reads missing records in batches according to a preset batch size, reads the current profile field value of the corresponding user master file for each record, completes the profile snapshot according to the template, and writes it back; the backfilling is carried out in batches and is idempotent—records that already have profile snapshots are skipped directly, and can be resumed from the current batch after an interruption, eventually converging until all existing team registration records have profile snapshots, so that the attribution criteria of existing data are consistent with the new data.

[0038] Example 5: Organizational Structure Tree Attribution and Integral Conversion As shown in Figure 4, the system pre-establishes an organizational structure tree. The tree's node data includes: a participating unit code table (student group unit codes 30-54, faculty group unit codes 10-29 and 55 / 56 in the sports meet scenario, satisfying the correspondence of "unit code × 100 = the starting point of the unit's number segment," allowing for reverse lookup of units based on numbers, serving as the authoritative attribution basis for number → unit), a college / unit basic information code table, and the unit affiliation field in the user's master file. Participation business records (registration records) are linked to the organizational structure field in the profile snapshot as leaf nodes of the tree, forming an attribution structure of "participating unit — subordinate organizational levels (classes / age groups, etc.) — participating members."

[0039] The attribution conversion from results to points is driven by attribution parameters in the event configuration: ranking points table (default 9-7-6-5-4-3-2-1, counting the top eight), doubling factor (doubled for breaking records, etc.), and team splitting strategy. Specifically: Individual competition results: Individual points are obtained by looking up the ranking points table according to the ranking, and are directly credited to the organizational node corresponding to the unit to which the participant belongs; Team competition results: The team score is split into unit-level scores according to the team splitting strategy (such as splitByWeight, which is equally distributed among the member units). The scores of the same member are only accumulated once in their respective nodes to avoid the same member being scored repeatedly across records. Special circumstances (insufficient enrollment quota, doubled group projects, etc.) are controlled by allocation: for example, if there are fewer than 8 applicants, one less will be admitted based on the actual number of applicants, and group projects will be split after being amplified by a doubling factor.

[0040] In a sports event scenario that includes 31 competition events, the above attribution simultaneously addressed the mixed situation of individual events, team events, and the number of participants from different units. The attribution results were verified to be consistent with manual calculations.

[0041] Example 6: Generation of Multi-View Rankings The node scores obtained from the same attribution calculation serve as intermediate results. These intermediate results are shared across all leaderboard views (overall team leaderboard, men's team leaderboard, and women's team leaderboard), and are generated only according to their respective view dimensions (whether to filter by gender, and how to sort after filtering). This avoids repeatedly performing full score aggregation for each leaderboard. When generating leaderboards, multiple organizations with the same node score are ranked equally (in the scenario of equal scores for ties, adjacent rankings are divided equally based on the number of ties, controlled by the event configuration switch). The three-leaderboard mode for the Games is enabled by the event configuration item (genderBoards='three'), verifying that the overall / men's / women's team scores and rankings for the four participating units in the verification scenario are correct.

[0042] Example 7: Aggregate caching and invalidation recalculation As shown in Figure 5, the rankings and aggregated scores are stored in an aggregated cache table (such as a college score ranking table) to avoid full real-time recalculation on each access. The system maintains a whitelist of actions that "will cause changes to scores": score release, score return, score clearing, manual addition / deduction of points, etc. After any action is successful, the affected aggregated cache is cleared and then recalculated: first, the primary keys of all records to be cleared are retrieved page by page according to the clearing conditions and deleted in batches (avoiding the upper limit of a single deletion), and then the changed score data is re-aggregated and written to ensure that no old results remain.

[0043] For redundant backups of aggregated cache and attribution details, the system first calculates a summary of the content to be backed up before backup: if the summary is the same as the most recent backup, it is skipped (no redundant backup is generated if the content has not changed), otherwise a new backup is written and only the most recent preset number of backups are retained, so that the number of backups and storage usage are controlled.

[0044] Example 8: Multidimensional Query Location The query interface supports location and aggregation along the organizational structure tree by participating member, participating unit, leaderboard view, event, and project. By participating member, users can query their registration, scores, and individual contributions to the team; by participating unit, users can view the unit's points composition under a specified leaderboard view; by leaderboard view / event / project, users can view the corresponding leaderboard and details. When querying by participating member, the logged-in user's identity is used as the query key, returning only the participating member's or authorized members' participation records and attribution results (ordinary users can only query their own records, while administrators can query any member). Personal data converges along the organizational structure tree, preventing leakage to unrelated users.

[0045] Example 9: Event-Level Ownership Authentication The system performs event-level attribution authentication on management requests: it parses the event corresponding to the request and determines the operator's permissions based on pre-established event attribution relationships—the system administrator has jurisdiction over all events; event administrators only have jurisdiction over assigned events or events they created; event creators only have jurisdiction over events they created. If the system determines the operator has management permissions, it allows triggering organizational structure tree attribution and aggregate cache invalidation recalculation; if the system determines the operator does not have management permissions, the corresponding operation is rejected. This mechanism ensures that actions such as "attribution and recalculation," which affect global results, can only be initiated by operators with attribution permissions to the target event, preventing unauthorized triggering that could lead to miscalculation or incorrect refresh of cross-event data.

[0046] Example 10: Single Event Scenario The above solution is also applicable in single-event scenarios (such as single-sport swimming competitions or ball game leagues): the profile field template only needs to enable a few fields (gender, unit, etc.); the organizational structure tree is simplified to two levels: "participating unit - participating member", without cross-group (student / faculty) dimensions; the leaderboard can generate only one overall leaderboard or generate sub-leaders as needed. When the number of participating units decreases, the number allocation, attribution conversion, and cache invalidation logic remain unchanged. The same solution can be reused across events of different scales without modifying the code; only the profile field set, attribution parameters, and view configuration need to be adjusted through event configuration data.

Claims

1. A multidimensional attribution method for competition results based on structured competition data, characterized in that, include: Profile field template configuration steps: In response to a configuration request for a target event, a profile field template for the target event is generated and stored. During the registration phase, the profile field template is instantiated as a data structure constraint for the competition's business data. The profile field template contains several profile field definitions, each of which includes at least a field key, a value range, and a purpose identifier. The purpose identifier indicates at least one purpose of the profile field in registration data collection, rule matching, and performance attribution. The profile field template drives the collection of competition business data, enabling different profile field sets to be used as needed for different events or different projects within the same event. Multi-path Redundancy Write and Consistency Resolution Steps: Receive participation requests submitted via at least two registration write paths. In each registration write path, read the current profile field value from the participant's user profile and redundantly write it into the corresponding participation business record according to the profile field template, forming a profile snapshot in the participation business record. Perform consistency resolution on duplicate participation requests or conflicting writes generated during the writing process of multiple registration write paths: Perform deduplication and idempotency processing on the participation business records of the same event, the same participant, and the same project according to a preset unique key. For the derived identifiers that need to be generated for the participating members to uniquely identify them within the scope of the competition, they are pre-allocated in memory according to the number range of the organization to which the participating member belongs, and conflicts are carried over accordingly; When the profile field in the user master file is changed afterward, the already generated profile snapshot will not be retroactively rewritten, so that the historical attribution is based on the profile at the time of the competition. Organizational structure tree attribution steps: Using the participating business record as the attribution leaf node, the participating score is converted into the group score of each level of organizational node according to the pre-established organizational structure tree. The organizational structure tree contains at least a multi-level node relationship of "participating unit - subordinate organizational level - participating member". Each participating business record is associated with the corresponding node in the organizational structure tree through the organizational level field of the unit to which it belongs in its profile snapshot. The converted group scores are aggregated level by level along the organizational structure tree, and lists with multiple views are generated according to at least the gender dimension.

2. The method according to claim 1, characterized in that, The portrait field definition also includes the collection source and snapshot strategy, and the method also includes a historical portrait backfilling step: The data collection sources include at least one of automatic reading from user profiles and manual entry from the registration interface; the snapshot strategy is used to indicate whether the profile field value is frozen after being written into the competition business record; After the portrait field template is generated, the registration interface dynamically renders the portrait collection form items according to the portrait field template; the server performs whitelist verification on the portrait fields in the registration request according to the portrait field template, and only accepts the portrait fields defined in the portrait field template, while the portrait fields outside the template are discarded. The historical profile backfilling step includes: for records with missing profile snapshots in the existing competition business records, reading the missing records in batches according to a preset batch size through a backfilling interface, reading the current profile field value of the user master corresponding to each record, filling in the profile snapshot according to the profile field template and writing it back; The backfilling is performed in batches and is idempotent; records that already have a portrait snapshot are skipped.

3. The method according to claim 1, characterized in that, The organizational structure tree attribution step further includes: Attribution parameters are read from the event configuration data. These parameters include a ranking points table, a doubling factor, and a team splitting strategy. For individual performance, the ranking points table is queried to obtain individual scores, which are then credited to the organizational node corresponding to the participating unit. For team performance, the team scores are split into unit-level scores according to the team splitting strategy and credited to the organizational nodes corresponding to the units of each team member. The scores of the same team member are only accumulated once in their respective organizational nodes. The doubling factor is used to double the scores for specified events or record-breaking performances.

4. The method according to claim 1, characterized in that, The list that generates multiple views based on at least the gender dimension includes: The overall leaderboard and sub-leaders by gender are generated based on the view configuration in the event configuration. Multiple views share the same intermediate results of node scores calculated along the organizational structure tree. Each view generates its own leaderboard by filtering and sorting the intermediate results according to its own view dimension. When multiple organizations have the same node score, they are ranked in the same place.

5. The method according to claim 1, characterized in that, The rankings of the multiple views are stored in an aggregated cache, and the method further includes aggregated cache invalidation and recalculation steps: When the competition results are changed in any of the following ways: published, returned, cleared, or manually adjusted, the affected aggregate cache is cleared and then recalculated: first, the primary keys of all records to be cleared are retrieved page by page according to the clearing conditions and deleted in batches, and then the results are re-aggregated and written according to the changed competition results to avoid leaving old aggregation results. For redundant backups of aggregated cache, first calculate the digest of the content to be backed up. If the digest is the same as the digest of the most recent backup, skip the current backup; otherwise, write it into the backup and retain only the most recent preset number of backups.

6. The method according to claim 1, characterized in that, It also includes multidimensional query and authentication steps: The system receives a query request carrying a query dimension, which includes at least one of the following: by participating member, by participating unit, by leaderboard view, by event, and by project. It then locates and aggregates the data along the organizational structure tree based on the query dimension, returning the scores or points under that dimension. For queries by participating member, the system uses the logged-in user's identity as the query key, returning only the profile and score attribution results of the participating member or those who are authorized to view them. Before triggering the invalidation and recalculation of performance attribution or leaderboard aggregation results, the management authority of the current operator over the target event is determined based on the event affiliation relationship. The event affiliation relationship includes three levels: system administrator, event administrator, and event creator, to prevent unauthorized operations from causing miscalculation of attribution results or accidental refresh of cross-event data.

7. A multidimensional attribution system for competition results based on structured competition data, characterized in that, include: The profile field configuration module is used to generate profile field templates in response to configuration requests for the target event and drive the registration interface to collect participation business data; the profile field template contains several profile field definitions, and each profile field definition contains at least a field key, a value range, and a purpose identifier; The multi-path redundant write module is used to receive participation requests submitted through at least two registration write paths, read the current profile field value from the user master file and redundantly write it into the participation business record according to the profile field template to form a profile snapshot, and perform consistency resolution for duplicate participation requests or conflicting writes. The consistency resolution includes deduplication and idempotency processing according to the preset unique key, memory pre-allocation and conflict continuation of the derived identifier according to the number segment of the organization unit, and not retroactively rewriting the generated profile snapshot when the profile field of the user master file is changed afterward. The multi-view aggregation and caching module is used to convert the competition results into group scores of organizational nodes at each level according to the organizational structure tree, and aggregate them level by level. It generates multiple view lists according to at least the gender dimension, stores the lists in the form of aggregated cache, and triggers the invalidation and recalculation of the aggregated cache when the competition results change. The performance attribution module is used to read the attribution parameters in the event configuration data and attribute individual and team performance results to the nodes at each level of the organizational structure tree. The team performance results are split into the organizational nodes corresponding to the units to which each member belongs according to the team splitting strategy. The query positioning module is used to receive query requests carrying query dimensions, locate and aggregate along the organizational structure tree, and return the scores or points results under that dimension.

8. The system according to claim 7, characterized in that, The portrait field configuration module is further used for: The registration interface dynamically renders the portrait collection form items based on the portrait field template, and the server performs whitelist verification on the portrait fields in the registration request based on the portrait field template; different subsets of portrait fields are used for different projects in the same event, and different event instances reuse the same portrait field template and allow the field value range to be covered.

9. The system according to claim 7, characterized in that, The multi-path redundant write module also includes a derived identifier allocator and a historical image backfiller: The derived identifier allocator prefetches the set of event-allocated identifiers into memory in a single page during batch writing, completes the pre-allocation in memory and immediately places the identifiers, and extends the position according to the step size in case of conflict; the historical portrait backfiller reads the records with missing portrait snapshots in the existing competition business records in batches according to the preset batch size and writes them back idempotently after supplementing the portrait snapshots from the user master file.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any one of claims 1 to 6.

Images