Virtual hierarchical identity periodic management method and device, and storage medium

Abstract

The application discloses a virtual level identity cycle management method and device and a storage medium, and belongs to the technical field of computers. The method comprises the following steps: after a first user is granted a virtual level identity, level information of the first user is divided into an actual level state and a display level identity; during a valid period of the virtual level identity, a client is controlled to display the virtual level identity in the display level identity, and the actual level state is continuously updated according to behaviors of the first user; and when the valid period ends, the display level identity is restored to an actual level identity indicated by the actual level state. The scheme fundamentally solves the conflict between virtual identity display and real level record from the technical architecture, guarantees the flexibility of periodic operation activities, and ensures the integrity and accuracy of real level data of users.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, device and storage medium for the periodic management of virtual hierarchical identities. Background Technology

[0002] With the development of internet technology, various live streaming, social networking, and online entertainment platforms widely adopt user level systems to incentivize user activity and spending. Operators often grant virtual tier status (such as monthly VIP, annual celebrity, etc.) to users who meet certain criteria within specific periods to enhance user satisfaction and platform activity.

[0003] Currently, the common practice is to directly modify the user's level field to a special level value, causing the client to display that special level. After the period ends, the administrator manually or via script restores the user's level field to its original value.

[0004] However, while this method can display special levels, the user's actual level growth due to consumption, activity, and other behaviors cannot be properly recorded and retained during the special level display period. If the recovery operation is not handled properly, the user's real level data can easily be overwritten by the special level value and permanently lost, which seriously affects the accuracy of user data and user experience. Summary of the Invention

[0005] This application provides a method, device, and storage medium for the periodic management of virtual level identities. From a technical architecture perspective, it fundamentally resolves the conflict between virtual identity display and real level records, ensuring both the flexibility of periodic operational activities and the integrity and accuracy of users' real level data. The technical solution is as follows: According to one aspect of this application, a method for periodic management of virtual level identities is provided, applied to a server, the method comprising: After granting a virtual level identity to the first user, the first user's level information is divided into actual level status and displayed level identity. The actual level status is used to record the actual level identity and upgrade trajectory of the first user determined based on preset indicators, and the displayed level identity is used to record the level type currently displayed to the outside world. During the validity period of the virtual level identity, the client is controlled to display the virtual level identity in the displayed level identity, while the actual level status is continuously updated according to the behavior of the first user; When the validity period expires, the displayed level identity will be restored to the actual level identity indicated by the actual level status.

[0006] According to another aspect of this application, a periodic management device for virtual level identities is provided, applied to a server, the device comprising: The segmentation module is used to segment the first user's level information into actual level status and displayed level identity after granting the first user a virtual level identity. The actual level status is used to record the first user's actual level identity and upgrade trajectory determined based on preset indicators, and the displayed level identity is used to record the level type currently displayed to the outside world. The control module is used to control the client to display the virtual level identity in the displayed level identity during the validity period of the virtual level identity, while keeping the actual level status continuously updated according to the behavior of the first user; The recovery module is used to restore the displayed level identity to the actual level identity indicated by the actual level status when the validity period ends.

[0007] According to another aspect of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the periodic management method for virtual hierarchical identities as described above.

[0008] According to another aspect of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the storage medium, the computer program being loaded and executed by a processor to implement the periodic management method for virtual hierarchical identities as described above.

[0009] According to another aspect of this application, a computer program product is provided, comprising a computer program executed by a processor to implement the virtual hierarchical identity periodic management method provided in various alternative implementations of the above aspects.

[0010] This application provides a periodic management scheme for virtual level identities, managing user level information by dividing it into two independent dimensions: actual level status and displayed level identity. During the validity period of the virtual level identity, the client prioritizes displaying the virtual identity to meet operational needs, while the user's actual level status is continuously updated based on their behavior without any impact. When the validity period expires, the displayed identity automatically reverts to the actual level, requiring no manual intervention. Therefore, this method fundamentally resolves the conflict between virtual identity display and real level recording from a technical architecture perspective, ensuring both the flexibility of periodic operational activities and the integrity and accuracy of users' real level data. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the implementation environment of a periodic management method for virtual hierarchical identities provided in the embodiments of this application; Figure 2 This is a flowchart of a periodic management method for virtual level identities provided in an embodiment of this application; Figure 3 This is a flowchart illustrating another method for periodic management of virtual level identities according to an embodiment of this application; Figure 4 This is a flowchart of another method for periodic management of virtual level identities provided according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a virtual level identity periodic management device according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a computer device provided according to an embodiment of this application.

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0015] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0016] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application 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 so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0017] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the media resources involved in this application were obtained with full authorization.

[0018] Figure 1 This is a schematic diagram illustrating the implementation environment of a periodic management method for virtual hierarchical identities provided in an embodiment of this application. See also... Figure 1 The implementation environment specifically includes: terminal device 101 and server 102. Terminal device 101 can be connected to server 102 via wireless network or wired network.

[0019] Terminal device 101 can be at least one of the following: smartphone, smartwatch, desktop computer, laptop, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), and laptop computer. An application can be installed and run on terminal device 101. This application is compatible with various media content platforms, covering scenarios such as music playback, online singing, live streaming, and on-demand video streaming, and can be in the form of a standalone app or mini-program. This application is associated with server 102, which provides background services to terminal device 101.

[0020] Terminal device 101 can refer to one of a plurality of terminal devices. This embodiment uses terminal device 101 as an example. Those skilled in the art will know that the number of the above-mentioned terminal devices can be more or less. For example, there can be several, dozens or hundreds, or more terminal devices. This application embodiment does not limit the number or type of terminal devices.

[0021] Server 102 can be at least one of a single server, multiple servers, a cloud computing platform, and a virtualization center. Optionally, the number of servers can be more or less, and this embodiment does not limit this. Of course, server 102 may also include other functional servers to provide more comprehensive and diversified services. In some embodiments, server 102 undertakes the main computing work, and terminal device 101 undertakes the secondary computing work; or, server 102 undertakes the secondary computing work, and terminal device 101 undertakes the main computing work; or, server 102 and terminal device 101 collaborate on computing using a distributed computing architecture. Server 102 can be connected to terminal device 101 and other terminal devices via a wireless network or a wired network. Optionally, the number of servers can be more or less, and this embodiment does not limit this.

[0022] Figure 2 This is a flowchart of a periodic management method for virtual level identities provided in an embodiment of this application, such as... Figure 2 As shown, this method is executed by a computer device, which can be... Figure 1 The server 102 shown includes the following steps: Step 201: After granting the virtual level identity to the first user, divide the first user's level information into actual level status and displayed level identity.

[0023] In this embodiment, after completing the process of assigning and granting virtual level identities for the current period, the server does not directly modify the user's original level field. Instead, it logically divides the user's level information into two independent but related parts: the actual level status and the displayed level identity. The purpose of this division is to decouple the granting and display of virtual level identities from the calculation and improvement of the user's actual level, fundamentally avoiding mutual overwriting of the two at the data level.

[0024] The server selects eligible target users from all users on the platform based on preset rating criteria and sorting rules, and grants those target users a virtual rating identity for the current period. This granting operation can be automatically executed by a periodic rating task initiated by the server.

[0025] The actual level status records the first user's actual level identity and upgrade trajectory based on preset indicators. This actual level is the genuine level determined by indicators accumulated by the user through behaviors such as consumption, interaction, and activity within the platform. These preset indicators may include wealth experience points, consumption points, and activity points. Granting a virtual level identity does not affect the existence or value of this actual level, nor does it change the calculation logic of the actual level.

[0026] The display level identity is used to record the currently displayed level type. It is a level type identifier returned by the server to the client, which the client then displays to the user. The display level identity has two possible values: when the user has not been granted any virtual level identity, the display level identity is set to the actual level identity, which is the current actual level indicated by the actual level status; when the user has been granted a virtual level identity and it is within its validity period, the display level identity is set to the virtual level identity, and the client will prioritize displaying this virtual level identity during the presentation.

[0027] Step 202: During the validity period of the virtual level identity, control the client to display the virtual level identity in the display level identity, while keeping the actual level status continuously updated according to the behavior of the first user.

[0028] In this embodiment, after a user is granted a virtual level identity, the virtual level identity has a certain validity period. During this validity period, the server can perform two management operations in parallel: one is to control the client to prioritize displaying the virtual level identity when displaying the user's level; the other is to keep the user's actual level status unaffected by the display switch and continue to update it based on the user's real-time behavior data.

[0029] The start time of the validity period can be the moment when the user is granted a virtual level identity, or the start time of a preset period. The end time of the validity period is the end time of the current preset period. For example, if the platform uses the calendar month as the virtual level identity granting period, and the server completes the leveling and granting operation at 00:00 on the first day of each month, then the validity period of the virtual level identity granted to the user in that month is from 00:00 on the first day of the month to 24:00 on the last day of the month.

[0030] The server can send display control commands or display data to the client, so that the client will prioritize displaying the virtual level identity instead of the user's actual level identity in various display scenarios such as the user's personal homepage, live broadcast information card, and user profile page.

[0031] In some embodiments, after receiving a user information query request from a client, the server retrieves the user's display level identity record. This query request may be triggered by the client when the user opens their personal homepage, enters a live stream, or views their profile. The server determines the user's current display level identity value: if the value points to a virtual level identity, the server returns the virtual level identity's name, icon, nameplate style, and other display information to the client; upon receiving this information, the client renders and displays the virtual level identity in the corresponding page or component. If the value points to an actual level identity, the server returns the user's actual level information to the client, and the client displays the user's actual level.

[0032] During the validity period of the virtual level identity, the server continues to monitor the user's behavioral data in real-time or near real-time, continuously updating the user's actual level status based on this data and recording the complete upgrade trajectory. Optionally, behavioral data is reported to the server by the client in real-time or periodically, and the server's level calculation module updates the user's experience value according to preset indicator calculation rules.

[0033] Step 203: At the end of the validity period, the displayed level identity will be restored to the actual level identity indicated by the actual level status.

[0034] In this embodiment, when the validity period of the virtual level identity expires, the server automatically switches the user's displayed level identity from the virtual level identity back to the actual level identity. After the expiration date, when the client displays the user's level, it restores the display of the user's current actual level identity.

[0035] For example, if the validity period of a virtual level identity is one calendar month, the validity period ends at 24:00 on the last day of that calendar month. The server can trigger a recovery operation at the end of the validity period through mechanisms such as scheduled tasks, event scheduling, or time wheels.

[0036] When restoring a user's level identity, the server can modify the value of the user's currently recorded display level identity, changing it from a virtual level identity to an actual level identity. Essentially, this restoration operation cancels the virtual level identity's priority at the display level, causing the display level identity value to revert to the user's current actual level identity.

[0037] It should be noted that all actual level upgrade records, experience point changes, and upgrade trajectory records that occur during the validity period of the user's virtual level identity are fully preserved and are unaffected by the recovery operation. After the recovery operation is completed, the actual level identity pointed to by the user's displayed level identity is the actual level value recorded in the user's current actual level status.

[0038] This application provides a periodic management scheme for virtual level identities, managing user level information by dividing it into two independent dimensions: actual level status and displayed level identity. During the validity period of the virtual level identity, the client prioritizes displaying the virtual identity to meet operational needs, while the user's actual level status is continuously updated based on their behavior without any impact. When the validity period expires, the displayed identity automatically reverts to the actual level, requiring no manual intervention. Therefore, this method fundamentally resolves the conflict between virtual identity display and real level recording from a technical architecture perspective, ensuring both the flexibility of periodic operational activities and the integrity and accuracy of users' real level data.

[0039] The above Figure 2The diagram shows the main flow of a periodic management method for virtual level identities provided in this application. The periodic management scheme for virtual level identities will be further explained below. Figure 3 This is a flowchart illustrating another method for periodic management of virtual level identities according to an embodiment of this application. The method is executed by a computer device, such as... Figure 3 As shown, the method includes: Step 301: At the beginning of each preset period, obtain a snapshot of user metrics at the end of the previous period.

[0040] In this embodiment of the application, the preset period refers to the time interval pre-set by the platform for periodically granting virtual level identities.

[0041] The specific duration and start and end times of the preset period can be configured by the platform operator according to business needs. In different application scenarios, the preset period can be a calendar month, a calendar week, a calendar quarter, or other custom time periods.

[0042] For example, in one application scenario, the platform grants virtual level identities on a calendar month basis, triggering the level assessment process at midnight on the first day of each month. In another application scenario, the platform grants virtual level identities on a calendar week basis, triggering the level assessment process at midnight on Monday. In yet another application scenario, the platform uses a specific marketing campaign period as the time interval, triggering the level assessment process at midnight on the start date of the campaign.

[0043] A virtual level identity is a special display level identity granted to a user within a preset period. Virtual level identities have higher display priority than regular real-world levels. Virtual level identities do not override a user's actual level status. Virtual level identities are time-limited and valid only within the preset period.

[0044] A virtual level identity is a special display level identity granted to a user within a preset period. Virtual level identities have higher display priority than regular real-world levels. Virtual level identities do not override a user's actual level status. Virtual level identities are time-limited and valid only within the preset period.

[0045] The server initiates a periodic ranking task at the start of each preset period. This ranking task is triggered by the server's internal scheduling module. The scheduling module manages and schedules the execution time and logic of various periodic tasks within the platform. Optionally, the scheduling module can be implemented based on Linux cron expressions, the Java Quartz framework, or a distributed task scheduling platform (such as XXL-JOB or Elastic-Job).

[0046] After the server initiates the rating task, it first retrieves a snapshot of user metrics from the end of the previous period. A user metric snapshot is a collection of data recorded and saved by the server at the end of the previous period (i.e., the instant before the start of the current period). This snapshot records the metric value for each user at that moment. Using snapshot data from the end of the previous period, rather than real-time data, during the rating process ensures the consistency of the rating benchmark. Even if the rating task is actually executed several minutes or longer after the start of the period due to network latency or system busyness, the snapshot data remains unchanged.

[0047] The user metric snapshot includes each user's user ID and corresponding metric value. Preset metrics include, but are not limited to, at least one of: wealth experience points, spending points, and activity points. Wealth experience points reflect a user's accumulated wealth on the platform and are typically positively correlated with their recharge and spending behavior. Spending points reflect the amount or frequency of a user's spending on the platform. Activity points reflect a user's activity level on the platform, including login frequency, interaction frequency, and online time.

[0048] For example, the platform uses 00:00 on the 1st of each month as the start time of its cycle. The server's timed scheduling module triggers the ranking task at 00:00 on the 1st of each month. After the ranking task is triggered, the server reads a snapshot of the user's wealth experience value saved at 24:00 on the last day of the previous month (i.e., one second before 00:00 on the 1st of the current month). This snapshot records the wealth experience value data of all users on the platform at that time. A record in this snapshot can be represented as: {user_id: 10001, wealth_experience: 28500, snapshot_time: 20XX-YY-ZZ 23:59:59}.

[0049] Step 302: Determine the identity granting object for the current period from multiple users according to the preset sorting rules.

[0050] In this embodiment, after the server obtains a snapshot of user metrics at the end of the previous period, it sorts the users in the snapshot according to a preset sorting rule, and determines the identity granting object for the current period based on the sorting result. The identity granting object is the target user who is granted a virtual level identity in the current period, referred to as the first user in this embodiment.

[0051] The preset sorting rules are the sorting criteria and filtering logic pre-set by the platform to select virtual level identity recipients from multiple users. The specific content of the preset sorting rules can be configured by the platform operator according to their operational strategy.

[0052] Optionally, the preset sorting rule can be: sorting by wealth experience points from highest to lowest, and selecting the user with the highest wealth experience points as the recipient of the identity for the current period. Alternatively, the preset sorting rule can be: sorting by a weighted composite score of consumption value and activity value, and selecting the user with the highest composite score as the recipient. Another preset sorting rule can be: first sorting by wealth experience points, and then, if the wealth experience points are the same, sorting by activity value, and selecting the user with the highest overall ranking.

[0053] It should be noted that the preset sorting rules listed above are merely illustrative examples and do not constitute a limitation on the scope of protection of this application. The preset sorting rules can also be set based on other indicators or combinations of indicators, and exclusion conditions can be introduced (e.g., excluding users who have already obtained virtual level identities, excluding users on blacklists, etc.), and the number of recipients can be set (e.g., granting to the top N users). This application does not limit the specific content of the preset sorting rules.

[0054] After determining the user to be granted an identity in the current period, the server generates a corresponding grant record for that user. The grant record contains at least the following information: a user identifier, indicating the user granted the virtual level identity; a grant time, recording the moment the virtual level identity was granted; and a period identifier for the current period, used to distinguish leveling events from different periods. The grant record may also include information such as the metric values ​​at the snapshot time and the ranking, for subsequent auditing and traceability.

[0055] For example, the server reads a snapshot of the wealth experience points at the end of the previous period. This snapshot contains wealth experience point data for multiple users. User A has 28,500 wealth experience points, User B has 27,300 wealth experience points, and User C has 25,200 wealth experience points. The default sorting rule is configured to sort in descending order of wealth experience points. The server sorts the user data in the snapshot, and the sorting result is: User A ranks first with 28,500 wealth experience points; User B ranks second with 27,300 wealth experience points; and User C ranks third with 25,200 wealth experience points. Based on this sorting result, the server determines that User A is the recipient of identity grants for the current period. The server generates an grant record for User A, which records information such as User ID A, grant time 20XX / YY / 10 / 00:00, and period ID 20XXYY.

[0056] Step 303: Grant virtual level identity to the identity granting object.

[0057] In this embodiment, after determining the identity granting target for the current period, the server grants the user a virtual level identity for the current period. The specific implementation of the granting operation includes, but is not limited to, writing a virtual level identity granting record into the user level management module on the server side. This granting record contains information such as user identifier, virtual level identity type, period version number, granting time, and validity period start and end times.

[0058] Optionally, during the process of granting virtual rating identities, the server generates a unique periodic version number for this rating event. The periodic version number uniquely identifies the rating event of the current period, preventing the rating task from being repeatedly executed due to retries, concurrency, or other abnormal conditions. The periodic version number includes at least one of the following: year, month, rating timestamp, and serial number. Optionally, the periodic version number adopts the following format: YYYYMMDD_HHMMSS_Sequence Number. For example, 20260701_000000_001 represents the first rating event triggered at 00:00:00 on July 1, 2026. The periodic version number can be simplified to the YYYYMM format, representing a rating event of a specific year and month. After generating the periodic version number, the server writes it into the rating record. The rating record is stored in the server's database or persistent storage medium. When writing the rating record, the server establishes a unique constraint at the database level based on the periodic version number field. The unique constraint ensures that only one rating record with the same periodic version number can exist in the database. When a rating task is retried due to network timeout, service restart, or other reasons, if the server detects that a valid rating record already exists for the current period version number, it will skip the repeated rating operation, not generate a new rating result, and directly enter the event compensation process.

[0059] Step 304: After granting the virtual level identity to the first user, divide the first user's level information into actual level status and displayed level identity.

[0060] In this embodiment, after granting the virtual level identity, the server logically divides the first user's level information into two independent parts: the actual level status and the displayed level identity. For ease of description, in this embodiment, "first user" refers to the user granted the virtual level identity. "First user" does not refer to a specific user, but rather to any user granted a virtual level identity who executes this method.

[0061] In this embodiment, the first user already possesses an actual level calculated based on the platform's level system before being granted a virtual level identity. This actual level is a genuine level determined by preset indicators (such as wealth experience points, consumption points, and activity points) accumulated by the user through continuous behaviors such as consumption, interaction, and activity within the platform. The granting of a virtual level identity does not affect the existence or value of this actual level, nor does it change the calculation rules and update logic of the actual level. The granting of a virtual level identity merely adds a display identity with display priority and a valid period to the user's existing actual level.

[0062] It's important to clarify that the partitioning operation in this step does not refer to physically splitting user level data into two completely independent database tables or files. Instead, it refers to creating two logically independent, functionally distinct level record dimensions for each user within the server's level status management module. These two dimensions are logically separate; at the storage level, they can be stored in different fields of the same data table, or in different data tables, and can be managed separately using different storage engines such as key-value pairs or document storage.

[0063] The actual level status and the displayed level identity are explained separately.

[0064] In this embodiment, the actual level status is used to record the actual level identity and upgrade trajectory determined by the first user based on preset indicators. The actual level status is a record maintained internally by the server that reflects the user's true level. Optionally, the actual level status includes at least one of the following: the user's actual level value, experience value, upgrade time, and upgrade trajectory. The actual level identity is the current level identity determined by the first user based on the actual level status. The actual level identity is a subset of the actual level status or a snapshot, reflecting the user's actual level at a certain moment.

[0065] In this embodiment, the display level identity is used to record the currently displayed level type. The display level identity is a level type identifier returned by the server to the client for the client to display to the user. The display level identity has multiple value states. When a user has not been granted any virtual level identity, the display level identity is set to the actual level identity. In this case, the client displays the user's actual level. When a user has been granted a virtual level identity and it is within its validity period, the display level identity is set to the virtual level identity. In this case, the client displays the virtual level identity. Optionally, the display level identity includes at least one of the following: the validity period of the virtual level identity, the period version number, the default nameplate name, the nameplate name edited by the user, and the name retained from the previous period.

[0066] In this embodiment, there is a clear correlation and operational rules between the actual level status and the displayed level identity. The validity period of the virtual level identity recorded in the displayed level identity is independent of the continuous updating of the actual level status. The activation and deactivation of the virtual level identity do not affect the recording and updating of the actual level status. Upgrades and changes in the actual level status do not affect the validity and display priority of the virtual level identity.

[0067] Step 305: During the validity period of the virtual level identity, control the client to display the virtual level identity in the display level identity, while keeping the actual level status continuously updated according to the behavior of the first user.

[0068] In this embodiment, after a first user is granted a virtual level identity, the virtual level identity has a preset time limit, i.e., a validity period. During the validity period, the server executes two management operations in parallel. One is a display control operation, which controls the client to prioritize displaying the virtual level identity rather than the actual level identity in various display scenarios. The other is a state update operation, which keeps the user's actual level status unaffected by display switching and continues to update it based on the user's real-time behavior data. These two management operations are logically independent and can be executed concurrently, constituting the operating mechanism of the dual-track state model.

[0069] Optionally, within the validity period of the virtual level identity, the server responds to the client's display data request by returning the currently valid display level identity and display data version number to the client. This allows the client to refresh its local display data and display the virtual level identity based on the display data version number. Display data requests can be triggered by various user actions or client events. For example, when a user opens their personal homepage, enters a live stream, views another user's profile card, or refreshes the page, the client sends a display data request to the server. The display data request must at least contain the user identifier of the user being queried. The display data version number is a monotonically increasing value or a timestamp. Whenever a user's display level identity changes (e.g., switching from a virtual level identity to an actual level identity, or switching from a virtual level identity in one cycle to a virtual level identity in the next cycle), the server updates the user's display data version number. After receiving the returned data, the client compares the display data version number in the returned data with the version number cached locally. If they do not match, the client refreshes its local display data based on the latest display data version number and displays the updated level identity. If they match, the client directly uses the locally cached data for display without re-rendering.

[0070] For example, in a live streaming scenario, when other users click on the current user's avatar to view that user's profile, the client sends a user information query request to the server. The server queries the user's displayed level and finds that the user is set to a virtual level of "Monthly VIP". The server returns the displayed level "Monthly VIP", the corresponding badge icon, and the current display data version number v20XXYY15_003 to the client. After receiving the returned data, the client compares the display data version number with the locally cached v20XXYY14_002 and finds that the version is updated. The client refreshes the local display data and displays the "Monthly VIP" badge in the profile card instead of showing the user's actual level.

[0071] Optionally, during the validity period of the virtual level identity, the server monitors the first user's behavioral data in real-time or near real-time. In response to the first user's behavioral data meeting preset indicator change conditions, the server updates the actual level identity and upgrade trajectory in the actual level status and records the actual level upgrade event. The first user's behavioral data includes, but is not limited to: the user's consumption behavior on the platform (such as purchasing virtual gifts, recharging memberships, etc.), interaction behavior (such as posting comments, liking, sharing content, etc.), and activity behavior (such as daily logins, online time, etc.). This behavioral data can be reported to the server in real-time by the client, or obtained by the server through calling the business system's interface. The preset indicator change conditions refer to the conditions that trigger a level update after the user's behavioral data accumulates to a certain threshold. The preset indicator change conditions could be: the user's accumulated wealth experience points reaching the threshold required for the next level. When the user's accumulated experience points reach the upgrade threshold, the server determines that the preset indicator change conditions are met and triggers the level update operation.

[0072] Optionally, the server can update the actual level value and upgrade trajectory in the actual level status as follows: The server updates the user's experience points according to preset indicator calculation rules. For example, 10 experience points are earned for every 1 yuan spent, and 5 experience points are earned for each login. When the accumulated experience points reach the upgrade threshold, the server upgrades the user's actual level value by one or more levels. The server records information such as the upgrade time, the level value before and after the upgrade, and adds it to the upgrade trajectory. The server can also record actual level upgrade events. An actual level upgrade event is a data object that records detailed information about this upgrade, including but not limited to: user identifier, level value before upgrade, level value after upgrade, upgrade time, event status (pending / triggered), etc. This upgrade event is used to subsequently determine whether to reissue upgrade animations or benefits.

[0073] For example, when the first user is granted a virtual level identity, their actual level status is: Level 15, Experience Points 28,000. On the 10th day of the virtual level identity's validity period, the first user spends 300 yuan worth of virtual gifts on the platform. The server calculates the experience points gained by the first user based on this spending behavior, using the formula: Spending Amount (yuan) × 10 points / yuan. The user gains 3,000 experience points, accumulating to 31,000 points, reaching the threshold for upgrading from level 15 to level 16 (e.g., 30,000 points). The server determines that the preset indicator change condition has been met. The server records in the user's actual level status: Actual Level Updated to Level 16, Experience Points Updated to 31,000. The server records an upgrade trajectory: {from:15, to: 16, time: 20XX-YY-10 20:15:30}. The server also generated an actual level upgrade event: {user_id: 10001, from_level: 15, to_level: 16, upgrade_time: 20XX-YY-10 20:15:30, status: pending}.

[0074] Since the first user is still within the validity period of their virtual level identity, the server-controlled client still displays the virtual level identity. The first user's actual level upgrade is fully recorded in the server's actual level status, but is not immediately displayed to the user or other users. During the validity period of the virtual level identity, if the first user undergoes multiple actual level upgrades, the server records each upgrade sequentially in the above manner, forming a complete upgrade trajectory.

[0075] Step 306: Obtain the set of virtual level rights corresponding to the virtual level identity and the set of actual level rights corresponding to the actual level status.

[0076] In this embodiment, a virtual level identity and an actual level identity are each associated with a set of rights. The virtual level rights set refers to the list of rights granted to the user within the validity period and bound to the virtual level identity. The actual level rights set refers to the list of rights granted based on the user's actual level value and bound to the user's actual level identity. Since a user simultaneously possesses both a virtual level identity and an actual level identity, theoretically, the user enjoys both types of rights concurrently. If the server directly and separately distributes the two types of rights to the user, problems such as duplicate distribution of the same right, omission of rights that should be distributed, or lower-level rights incorrectly overriding higher-level rights may occur. Therefore, it is necessary to merge the two types of rights.

[0077] After granting a virtual level identity to the first user, the server retrieves the set of virtual level rights corresponding to that identity from the rights management module. The set of virtual level rights contains one or more rights items. Each rights item includes at least the following information: rights identifier, rights name, rights type, value level, and validity period.

[0078] Similarly, based on the first user's current actual level status, the server retrieves the set of actual level benefits corresponding to that actual level status from the benefits management module. This set of actual level benefits also contains one or more benefit items. Each benefit item includes at least the benefit identifier, benefit name, benefit type, value level, and validity period.

[0079] For example, the set of virtual level benefits associated with the virtual level identity "Monthly VIP" includes: exclusive avatar frame (value level: high), room entry effect (value level: medium), and monthly gift pack (value level: medium). The first user's actual level identity is level 16, and the set of actual level benefits associated with it includes: level 16 exclusive nameplate (value level: high), level 16 room entry effect (value level: low), and level 16 weekly gift pack (value level: low).

[0080] It should be noted that step 306 can be executed after step 305, or in parallel with step 305, or triggered when the right-of-interest distribution time arrives (e.g., when a user logs in for the first time or enters a specific page for the first time). The operation of obtaining the set of rights is logically independent of the display control operation and the state update operation. The specific execution time of step 306 is not strictly limited in this embodiment.

[0081] Step 307: Merge the virtual level rights set and the actual level rights set according to the preset merging rules to generate a merged rights distribution list.

[0082] In this embodiment, after obtaining the virtual tier benefits set and the actual tier benefits set, the server does not directly distribute all benefits items in both sets to the user. Instead, it merges the two sets according to a preset merging rule to generate a merged benefits distribution list. Each benefit item in this distribution list is the final determined item after merging, and there are no duplicates, conflicts, or omissions.

[0083] In some embodiments, the preset merging rules include at least one of the following: (1) For similar rights, the rights with the highest value or the largest effective scope are selected for distribution according to the preset value level or priority.

[0084] Similar rights refer to rights items with the same or similar types of rights. For example, rights that are both related to avatar display or both related to entrance effects are considered similar rights. When merging the rights, the server identifies similar rights items in the two sets, compares their value level or priority, and selects the right item with the highest value or the largest effective scope to include in the rights distribution list. Similar rights items that are not selected will not be distributed.

[0085] For example, the virtual level benefits set includes an exclusive avatar frame (value level: high), and the actual level benefits set also includes a level 16 exclusive nameplate (value level: high). Both are avatar display benefits and belong to the same category. The server compares the value levels of the two, and both are high-level. The server further compares the validity period of the two; the virtual level identity is valid for one month, while the actual level benefits have no fixed expiration date (it varies with the level). The server selects the actual level benefit with the largest validity period, the level 16 exclusive nameplate, for distribution.

[0086] (2) Accumulate the quantity of rights that can be stacked or merge their validity periods.

[0087] Stackable benefits refer to a type of benefit that allows multiple benefits to be effective simultaneously and can be accumulated in terms of quantity or duration. For example, gift package benefits typically allow multiple gift packages to be issued to users at the same time; membership experience benefits typically allow for the accumulation of duration. The server identifies stackable benefit items in two sets and either accumulates their quantities or combines their validity periods.

[0088] For example, the virtual tier benefits set includes a monthly gift pack (1 per month), and the actual tier benefits set includes a weekly gift pack (1 per week). Both are stackable gift pack benefits. The server adds up the quantities of the two to generate a combined benefit item: a monthly gift pack + a weekly gift pack (a total of 4 weekly gift packs and 1 monthly gift pack per month, so users can receive a total of 5 gift packs per month).

[0089] (3) The effective rights are determined according to the preset coverage rules for mutually exclusive rights, so as to avoid the lower-level rights from covering the higher-level rights.

[0090] Mutually exclusive rights refer to rights that are mutually exclusive and cannot be active simultaneously. For example, room entry effects are usually mutually exclusive rights; a user can only have one room entry effect active at a time. The server identifies mutually exclusive rights items in two sets and determines which right will ultimately take effect according to preset overriding rules (such as "higher-level rights overriding lower-level rights" or "virtual-level rights overriding actual-level rights").

[0091] The virtual tier benefits include a special entrance effect (Vibrant Version), while the actual tier benefits include a special entrance effect (Standard Version). These are mutually exclusive benefits and cannot be active simultaneously. The default overriding rule is that higher-tier benefits override lower-tier benefits. The server compares the value levels of the two; the Vibrant Version is considered more valuable, and the Standard Version is less so. The server determines that the Vibrant Version will be active and will not issue the Standard Version.

[0092] In some embodiments, during the generation of the merged benefits distribution list, the server also generates a benefit idempotent key based on at least one of the following: user identifier, benefit identifier, periodic version number, level source, and distribution batch. The server performs deduplication on each benefit in the benefits distribution list based on the benefit idempotent key, ensuring that benefits with the same idempotent key that already exist in the distribution record are not distributed again.

[0093] The user identifier is used to distinguish different users. The benefit identifier is used to distinguish different benefit items. The period version number is used to distinguish grading events in different periods, ensuring that the same benefit can be issued normally in different periods (the same benefit in different periods has different period version numbers and different idempotent keys). The level source field is used to distinguish whether the benefit comes from a virtual level identity or an actual level identity. The issuance batch field is used to distinguish different issuance times of the same benefit within the same period.

[0094] An idempotent key can be generated by concatenating the values ​​of the aforementioned fields into a string and then calculating its hash value (such as an MD5 hash). For example, the server concatenates user identifier 10001, equity identifier avatar_frame_001, cycle version number 20XXYY01_000000_001, level source virtual, and distribution batch 001 into a single string, calculates the MD5 hash value of this string, and uses this hash value as the idempotent key.

[0095] During the generation of the rights distribution list, the server generates a corresponding idempotent key for each rights item in the list. The server checks each idempotent key to ensure it already exists in the rights distribution record database. The rights distribution record database records the idempotent keys for all successfully distributed rights. If an idempotent key already exists in the distribution record, it means the right has already been successfully distributed previously, and the server removes the right item from the current distribution list to avoid duplicate distribution. If the idempotent key does not exist in the distribution record, it means the right has not yet been distributed, and the server retains the right item in the distribution list and writes the idempotent key to the distribution record database after subsequent distributions are completed.

[0096] In some embodiments, when a first user undergoes an actual level upgrade within the validity period of their virtual level identity, the server selects different processing methods based on a pre-configured pattern.

[0097] Correspondingly, when the first user undergoes an actual level upgrade within the validity period, the actual level upgrade event of the first user is obtained; in the instant mode, the actual level upgrade animation event is generated immediately, and the higher of the virtual level benefits corresponding to the virtual level identity and the actual level benefits corresponding to the actual level upgrade is issued; in the delayed mode, the actual level upgrade event and the benefits to be reissued are recorded, and the actual level upgrade animation event and the issuance event of the benefits to be reissued are triggered when the validity period ends.

[0098] In real-time mode, when the server detects that the first user has undergone an actual level upgrade within the validity period of their virtual level identity, the server immediately generates an actual level upgrade animation event. This animation event is used to send a command to the client, triggering the client to play the animation effect of the user's actual level upgrade. Simultaneously, the server obtains the actual level benefits corresponding to this upgrade and merges them with the user's currently held virtual level benefits. The merging rules are executed according to the aforementioned priority selection rules, superposition merging rules, and mutual exclusion overriding rules, selecting the higher-value or better benefits for distribution.

[0099] In delayed mode, when the server detects that the first user has undergone an actual level upgrade within the validity period of their virtual level identity, the server only records the actual level upgrade event and the information on pending benefits. It does not immediately generate an upgrade animation event or trigger the issuance of benefits. The server sets the event status of the upgrade event to "pending trigger" and stores the relevant information on the pending benefits in the "pending issuance" record. When the validity period of the virtual level identity expires, the server queries for the existing upgrade event and pending benefit record, and triggers the upgrade animation event and benefit reissue uniformly during the recovery process after the expiration of the validity period.

[0100] Step 308: During the validity period of the virtual level identity, when the first user's displayed level identity is a virtual level identity, return the custom nameplate editing entry permission to the client corresponding to the first user.

[0101] In this embodiment, the virtual level identity is associated with a nameplate name. The nameplate name is the level title text displayed on the client's user profile card, personal homepage, live stream information card, etc. Nameplate names include two types: system default nameplate names and user-defined nameplate names. System default nameplate names are those preset by the platform for virtual level identities, such as Monthly VIP or Honorary Member. User-defined nameplate names are personalized nameplate names entered and submitted by the user through an editing portal, such as a user-edited "My Exclusive Title."

[0102] The server can display a custom nameplate editing portal to the first user during the validity period of the virtual level identity. This editing portal is only visible in the user interface of the user who has been granted a virtual level identity in the current period. Other users who have not been granted a virtual level identity will not see this portal.

[0103] For example, when the first user accesses the privilege settings page or personal homepage through a client, the client sends a page data request to the server. This request carries the first user's user identifier and the identifier of the currently accessed page. After receiving the request, the server queries the user's display level identity record based on the user identifier. The server reads the display type field from the display level identity record. If the display type field is set to virtual (i.e., virtual level identity) and the current time is within the start and end time range of the validity period, the server sets the visibility permission field of the custom nameplate editing entry to visible when constructing the page return data. After receiving the returned data, the client determines whether to render the page element of the custom nameplate editing entry based on the value of this field. If the field is visible, the client renders and displays the custom nameplate editing entry on the privilege settings page, and the user can enter the nameplate editing interface through this entry. If the display type field is set to actual (i.e., actual level identity), the server sets the visibility permission field to invisible, and the client does not render the editing entry. Ordinary users who have not been granted a virtual level identity will not see the custom nameplate editing entry when accessing the privilege settings page.

[0104] In some embodiments, this application also provides a function for importing nameplate names in a continuous periodic granting scenario. A continuous periodic granting scenario refers to a scenario where the same user is identified as an identity granting object and continuously obtains virtual level identities in two or more consecutive preset periods. In this scenario, when the server returns the nameplate editing page data for the current period to the first user, it checks whether the first user was also granted a virtual level identity in the previous period. If the detection result is yes, the server reads the reserved name field of the previous period from the first user's display level identity record to obtain the nameplate name edited and used by the first user in the previous period. The server returns this nameplate name from the previous period as historical name data along with the page data to the client. That is, when the first user is granted a virtual level identity in two consecutive preset periods, the nameplate name edited in the previous period is imported into the nameplate editing input box of the current period as a historical name. When the client renders the nameplate editing input box, it displays the historical name in the recommended area or historical name area of ​​the input box for the user to refer to and select. At the same time, the server resets the default display nameplate name for the current period to the system default name. Instead of directly using the custom name from the previous cycle.

[0105] Step 309: In response to the nameplate name editing request submitted by the first user through the editing portal, verify whether the first user is still within the validity period of the virtual level identity, and update the nameplate name for the current period after the verification is passed.

[0106] In this embodiment, after the first user enters a new nameplate name through the client's editing entry and clicks submit, the client sends a nameplate name editing request to the server. This nameplate name editing request includes at least: a user identifier, used to identify the user initiating the editing request; the new nameplate name, which is the text entered and desired by the user; and a request timestamp, used to identify the time the request was initiated.

[0107] After receiving the edit request, the server first verifies whether the first user is still within the validity period of their virtual level identity. Optionally, the verification process includes: the server querying the user's display level identity based on the user identifier to obtain the end time of the virtual level identity's validity period. The server compares the current time with the end time of the validity period. If the current time is before the end time of the validity period, the verification passes. If the current time is after the end time of the validity period, the verification fails, and the server returns an edit failure response to the client, indicating that the user's virtual level identity has expired.

[0108] Optionally, after successful verification, the server can further verify the length and validity of the new nameplate name. For example, the server can verify whether the new nameplate name exceeds 5 Chinese characters or an equivalent character length. The server can also verify whether the new nameplate name contains sensitive words or illegal characters. For example, the server can call a sensitive word filtering service or a regular expression matching method for verification.

[0109] After the validity check passes, the server updates the nameplate name for the current period to the new name submitted by the user. The server stores the updated nameplate name in the `custom_badge` field of the display level identity record. After the update is complete, the server updates the display data version number and returns an edit success response to the client. Upon receiving the success response, the client refreshes its local display data to show the updated custom nameplate name.

[0110] Step 310: At the end of the validity period, the displayed level identity will be restored to the actual level identity indicated by the actual level status.

[0111] In this embodiment, when the validity period of the virtual level identity expires, the server automatically switches the first user's displayed level identity from the virtual level identity back to the actual level identity. This operation ensures that after the expiration date, the client displays the first user's actual level identity instead of the virtual level identity.

[0112] Optionally, this step includes the following sub-steps.

[0113] Sub-step 310A: Query whether there are any untriggered actual level upgrade events for the first user within the validity period.

[0114] The server can query whether the user has any untriggered upgrade events recorded within the validity period, based on the user's user ID and period version number. An untriggered upgrade event status indicates that the server has not yet generated upgrade animation events and rights reissue events for that upgrade.

[0115] Sub-step 310B: If it exists, generate the upgrade animation event and the rights reissue event corresponding to the actual level upgrade event, and after the upgrade animation event and the rights reissue event are completed, switch the displayed level identity to the actual level identity.

[0116] If an actual level upgrade event is not triggered, the server generates an upgrade animation event and a benefits reissue event corresponding to that upgrade event. The upgrade animation event instructs the client to play the upgrade animation. The benefits reissue event is used to issue the actual level benefits corresponding to the upgrade to the user. The server adds the upgrade animation event and benefits reissue event to the pending event queue. After the upgrade animation event and benefits reissue event are completed, the server will display the level identity switched to the actual level identity.

[0117] After the recovery operation is complete, the server generates a new display data version number and invalidates the old periodic cache. Optionally, the server updates the display data version number to a new incrementing value or timestamp. The server notifies the cache management module to invalidate the cached data associated with the old period. Cache invalidation can be achieved by actively deleting the corresponding cache key through a caching framework (such as Redis), or by setting a cache expiration time to make it automatically invalid.

[0118] For example, a user's actual level increases from 15 to 16 during the validity period of their virtual VIP status. The server records the upgrade event when it occurs, but does not trigger the animation or benefit distribution. At the end of the validity period, the server detects this untriggered event. The server generates an upgrade animation event and obtains the level 16 gift pack benefits from the corresponding level 16 benefits. The server submits the upgrade animation event and benefit reissue event to the event queue. After the events are executed, the server switches the user's displayed VIP status from Monthly VIP to Level 16. The server updates the displayed data version number from "v20XX0715_003" to "v20XX0801_001". The server notifies the cache management module to invalidate the old cached data related to the user.

[0119] In some embodiments, the expiration date of a virtual level identity coincides with the start date of the next virtual level identity cycle. When a user granted a virtual level identity changes between the current and next cycle, the server performs an atomic migration operation within the same transaction. An atomic migration operation combines multiple change operations involving different users and different data tables into an indivisible execution unit. All operations within this unit either execute successfully and are committed, or they fail and are rolled back. Atomic migration operations are implemented through the database's transaction mechanism or a distributed transaction coordination mechanism, ensuring that there is no intermediate inconsistency during cycle switching where some users have switched while others have not. In this scenario, the first user is the one granted a virtual level identity in the previous cycle, and this user is no longer granted a virtual level identity in the current cycle. The second user is the newly determined identity grantee in the current cycle. The current cycle refers to the cycle following the expiration of the first user's virtual level identity.

[0120] Atom migration operations include the following steps.

[0121] Step 1: The server reverts the first user's displayed level identity to the actual level identity indicated by the first user's current actual level status.

[0122] Step 2: If the user who was granted a virtual level identity changes, update the second user's display level identity to the virtual level identity. The second user will be the user who was granted a virtual level identity in the next cycle.

[0123] Optionally, the server sets the display type field in the second user's display level identity record to virtual and writes the relevant information of the virtual level identity (validity period, default nameplate name, periodic version number, etc.) into the display level identity record.

[0124] Step 3: Generate the virtual level upgrade animation event and the virtual level benefits distribution event for the second user.

[0125] The upgrade animation event is used to instruct the client to play the upgrade animation effect when the second user obtains the virtual level identity. The benefits distribution event is used to distribute the virtual level benefits bound to the virtual level identity to the second user.

[0126] Step 4: Generate a new display data version number and invalidate the old periodic cache.

[0127] The server generates a new version number for the display data and sends a notification to the cache management module that the old period's cache has expired, so that all clients can obtain the latest period's display data in subsequent requests.

[0128] In some embodiments, if the first user and the second user happen to be the same user (i.e., the user obtains virtual level identity for two consecutive periods), the server does not need to perform the aforementioned rollback operation and new user identity writing operation. The server only needs to update the period version number and validity start and end time in the user's display level identity record to the corresponding data for the current period, and keep the display type field as virtual. The generation of upgrade animation events and benefit distribution events, the updating of display data version numbers, and cache invalidation are still executed normally according to the above steps.

[0129] In some embodiments, to ensure the correct execution of atomic migration operations in a concurrent environment, the server applies a concurrency control mechanism to the relevant periodic version number or user level status record before updating the displayed level identity or level status record. The concurrency control mechanism can be implemented using optimistic locking or distributed locking. Accordingly, an optimistic lock or distributed lock is applied to the periodic version number; when a concurrency conflict is detected, the process resumes from its breakpoint based on the periodic version number and the event execution status.

[0130] Optimistic locking is a concurrency control mechanism. When updating data, the server checks if the data version number has changed. If it hasn't changed, the update is performed; otherwise, the update is abandoned or retried. Distributed locking is a locking mechanism that spans multiple server nodes. Before updating data, the server acquires a distributed lock to ensure that only one thread or process can perform the update operation at any given time.

[0131] When the server detects a concurrent conflict (such as an inconsistent optimistic lock version number or a distributed lock acquisition failure), it performs a breakpoint resume based on the period version number and the event execution status. Breakpoint resume means that the server locates the current period's classification record and related event records based on the period version number, queries the current execution status of each event record, and identifies which operations have been completed, which have not yet been executed, or which have failed. The server only executes operations that are not yet completed, skips completed operations, and continues the entire period switching process from the breakpoint, avoiding the duplication of processed completed events due to retries.

[0132] In this embodiment, when a rating task, benefits distribution task, animation event delivery task, or display cache refresh task fails, the task compensation server scans rating records, identity records, benefits distribution records, animation event records, and display version records according to the periodic version number. The task compensation server identifies the status of each record, including completed, incomplete, and failed states. Benefits with existing idempotent keys are not reissued. Undelivered animation events are redelivered. Display data version numbers are regenerated for unrefreshed display caches. Through this compensation process, the system can still guarantee the eventual consistency of user identity, benefits, animations, and cross-platform display in the event of task retries, service anomalies, or message delivery failures.

[0133] To make the solution provided in this application easier to understand, the following is a brief explanation. Figure 4 This application provides further details on the periodic management scheme for virtual level identities. For example... Figure 4 As shown, Figure 4This is a flowchart of another method for periodic management of virtual level identities according to an embodiment of this application. The process includes: Step 401, triggering the leveling task at 00:00 on the 1st of each month. At the beginning of each preset period (e.g., a calendar month), i.e., at 00:00 on the 1st of each month, the server's timed scheduling module automatically triggers the leveling task for the current period. This task is driven by a preset timed strategy and requires no manual intervention. Step 402, reading a snapshot of the entire network's wealth experience values. After the leveling task is triggered, the server reads a snapshot of the entire network's user wealth experience values ​​saved at the end of the previous period (i.e., the last second of the previous month) from the database. This snapshot is static data, recording the wealth experience values ​​of all users at that time, serving as the sole data basis for this leveling, ensuring the consistency and fairness of the sorting benchmark. Step 403, determining virtual level users by sorting by experience value. The server sorts all users in the snapshot according to their wealth experience values ​​from high to low according to preset sorting rules, and determines the target users who should be granted virtual level identities in the current period. For example, the user with the highest wealth experience value ranking is selected as the grant recipient. Step 404, generating a period version number. After identifying the target user, the server generates a unique periodic version number for this rating event. This version number can include information such as year, month, rating timestamp, and task serial number, used to uniquely identify the rating record for the current period and prevent duplicate ratings due to task retries. Step 405: Update the user's displayed level to a virtual level. The server updates the target user's displayed level identity to a virtual level identity. After the update, the client's level display will prioritize showing this virtual level identity, rather than the user's actual level. Step 406: Retain the user's actual level status. While updating the displayed level, the server retains the user's actual level status without making any modifications. The user's actual level value, experience points, upgrade trajectory, and other data accumulated based on consumption, interaction, and other behaviors continue to be maintained independently in the background and are not overwritten by the virtual level identity. Step 407: Merge virtual level benefits with actual level benefits. The server obtains the benefit set corresponding to the virtual level identity and the benefit set corresponding to the user's actual level identity, and merges them according to preset merging rules. Merging rules include: selecting the highest value priority for similar benefits, accumulating the quantity or merging the validity period for stackable benefits, and determining the effective benefits for mutually exclusive benefits according to the overriding rules. Step 408: Issue Benefits and Trigger Upgrade Animation. The server issues benefits to users according to the merged benefits distribution list, and simultaneously triggers the virtual level upgrade animation displayed on the client. Step 409: Generate Default Custom Nameplate. The server generates a corresponding nameplate name for users who have obtained virtual level identities. The nameplate name includes the system default name, and users can edit their own custom name within the validity period. Step 410: Unified Display on Mobile / PC. The server returns consistent display level identity, nameplate name, and validity period data to mobile devices, PCs, live streaming rooms, and other platforms through a unified display interface, ensuring that the level display seen by users on different devices is completely consistent.Step 411: Re-classify for the next cycle. When the current cycle ends, the server triggers the classification task again, rereads the user indicator snapshot at the start of the next cycle, and begins a new round of classification process. Step 412: Determine if the virtual level user has changed. The server compares the newly determined target user in the current cycle with the virtual level user in the previous cycle to see if they are the same user, and performs different migration operations based on the comparison result. Step 413: If changed, the original user is reverted to their actual level. If the target user in the current cycle changes, the original virtual level user's display level identity is reverted to their actual level identity. Step 414: If not changed, the current user's virtual level identity is continued. If the target user in the current cycle is the same as the previous cycle (i.e., the same user has continuously obtained virtual level identities), no revert operation is needed; the server directly continues the user's virtual level identity to the next cycle, only updating periodic data such as validity period and cycle version number. Step 415: New user becomes a virtual level. The new target user's display level identity is updated to their virtual level identity.

[0134] This application provides a periodic management scheme for virtual level identities, managing user level information by dividing it into two independent dimensions: actual level status and displayed level identity. During the validity period of the virtual level identity, the client prioritizes displaying the virtual identity to meet operational needs, while the user's actual level status is continuously updated based on their behavior without any impact. When the validity period expires, the displayed identity automatically reverts to the actual level, requiring no manual intervention. Therefore, this method fundamentally resolves the conflict between virtual identity display and real level recording from a technical architecture perspective, ensuring both the flexibility of periodic operational activities and the integrity and accuracy of users' real level data.

[0135] It should be noted that this application may display prompt interfaces, pop-ups, or output voice prompts before and during the collection of user data. These prompt interfaces, pop-ups, or voice prompts are used to inform the user that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt interface or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected in this application is collected with the user's consent and authorization, and the collection, use, and processing of related user data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0136] It should be noted that the order of the method steps provided in the embodiments of this application can be appropriately adjusted, and the steps can also be added or removed as appropriate. Any method variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application, and therefore will not be elaborated further.

[0137] Figure 5 This is a schematic diagram of the structure of a virtual level identity periodic management device provided according to an embodiment of this application. Figure 5 As shown, the device includes: a division module 501, a control module 502, and a recovery module 503.

[0138] The partitioning module 501 is used to partition the first user's level information into actual level status and displayed level identity after granting the first user a virtual level identity. The actual level status is used to record the first user's actual level identity and upgrade trajectory determined based on preset indicators, and the displayed level identity is used to record the level type currently displayed to the outside world. Control module 502 is used to control the client to display the virtual level identity in the display level identity during the validity period of the virtual level identity, while keeping the actual level status continuously updated according to the behavior of the first user; The recovery module 503 is used to restore the displayed level identity to the actual level identity indicated by the actual level status when the validity period ends.

[0139] In some embodiments, the segmentation module 501 is configured to obtain a snapshot of user metrics at the end of the previous period at the beginning of each preset period; determine the identity granting object for the current period from multiple users according to a preset sorting rule; and grant virtual level identity to the identity granting object.

[0140] In some embodiments, the partitioning module 501 is used to generate a unique periodic version number for this classification event. The periodic version number includes at least one of the following: year, month, classification timestamp, and serial number. The classification record is written according to the periodic version number, and a unique constraint is established based on the periodic version number when writing. If a valid classification record with the periodic version number is detected, the duplicate classification is skipped and the event compensation process is entered.

[0141] In some embodiments, the actual level status includes at least one of the following: the user's actual level value, experience value, upgrade time, and upgrade trajectory, and the actual level identity is the current level identity determined by the first user based on the actual level status.

[0142] In some embodiments, the displayed class identity includes at least one of the following: the validity period of the virtual class identity, the period version number, the default nameplate name, the nameplate name edited by the user, and the name retained from the previous period.

[0143] In some embodiments, the control module 502 is configured to return the currently valid display level identity and display data version number to the client during the validity period of the virtual level identity, so that the client refreshes the local display data and displays the virtual level identity according to the display data version number.

[0144] In some embodiments, the control module 502 is configured to update the actual level identity and upgrade trajectory in the actual level status and record the actual level upgrade event in response to the first user's behavior data meeting the preset indicator change conditions during the validity period of the virtual level identity.

[0145] In some embodiments, the recovery module 503 is used to query whether there is an untriggered actual level upgrade event for the first user within the validity period; if so, it generates an upgrade animation event and a rights reissue event corresponding to the actual level upgrade event, and after the upgrade animation event and the rights reissue event are completed, it switches the displayed level identity to the actual level identity.

[0146] In some embodiments, the control module 502 is used to obtain the set of virtual level rights corresponding to the virtual level identity and the set of actual level rights corresponding to the actual level status; and to merge the set of virtual level rights and the set of actual level rights according to a preset merging rule to generate a merged rights distribution list.

[0147] In some embodiments, the preset merging rules include at least one of the following: For similar rights, the rights with the highest value or the largest effective scope are selected for distribution according to a preset value level or priority. Accumulate the quantity or merge the validity periods of overlapping rights; The effective rights are determined according to the preset coverage rules for mutually exclusive rights, so as to avoid lower-level rights from covering higher-level rights.

[0148] In some embodiments, the control module 502 is configured to generate an idempotent key for a right based on at least one of a user identifier, a right identifier, a periodic version number, a level source, and a distribution batch; and to perform deduplication processing on each right in the right distribution list based on the right idempotent key, and to prevent the duplicate distribution of rights that already have the same idempotent key in the distribution record.

[0149] In some embodiments, the recovery module 503 is further configured to perform the following atomic migration operations in the same transaction at the end of the current period: if the user granted virtual level identity changes, update the display level identity of the second user to the virtual level identity, the second user being the user granted virtual level identity in the next period; generate the virtual level upgrade animation event and virtual level benefits distribution event for the second user; generate a new display data version number and invalidate the old period cache.

[0150] In some embodiments, the recovery module 503 is further configured to apply an optimistic lock or a distributed lock to the periodic version number; when a concurrent conflict is detected, it performs a breakpoint resumption based on the periodic version number and the event execution status.

[0151] In some embodiments, the control module 502 is further configured to, during the validity period of the virtual level identity, when the first user's displayed level identity is a virtual level identity, return the custom nameplate editing entry permission to the client corresponding to the first user; in response to the nameplate name editing request submitted by the first user through the editing entry, verify whether the first user is still within the validity period of the virtual level identity, and update the nameplate name of the current period after the verification is passed.

[0152] In some embodiments, the recovery module 503 is further configured to, when the first user is granted a virtual level identity in two consecutive preset periods, bring the nameplate name edited in the previous period as the historical name into the nameplate editing input box of the current period; and reset the default display nameplate name of the current period to the system default name.

[0153] In some embodiments, the recovery module 503 is further configured to: acquire the actual level upgrade event of the first user when the first user undergoes an actual level upgrade within the validity period; in the instant mode, immediately generate an actual level upgrade animation event and distribute the higher of the virtual level benefits corresponding to the virtual level identity and the actual level benefits corresponding to the actual level upgrade; in the delayed mode, record the actual level upgrade event and the benefits to be reissued, and trigger the actual level upgrade animation event and the distribution event of the benefits to be reissued at the end of the validity period.

[0154] This application provides a periodic management scheme for virtual level identities, managing user level information by dividing it into two independent dimensions: actual level status and displayed level identity. During the validity period of the virtual level identity, the client prioritizes displaying the virtual identity to meet operational needs, while the user's actual level status is continuously updated based on their behavior without any impact. When the validity period expires, the displayed identity automatically reverts to the actual level, requiring no manual intervention. Therefore, this method fundamentally resolves the conflict between virtual identity display and real level recording from a technical architecture perspective, ensuring both the flexibility of periodic operational activities and the integrity and accuracy of users' real level data.

[0155] It should be noted that the virtual level identity periodic management device provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the virtual level identity periodic management device and the virtual level identity periodic management method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0156] Embodiments of this application also provide a computer device, which includes a processor and a memory, wherein the memory stores a computer program, which is loaded and executed by the processor to implement the virtual level identity periodic management method provided in the above-described method embodiments.

[0157] Figure 6 This is a schematic diagram of the structure of a computer device provided according to an embodiment of this application.

[0158] Computer device 600 includes a central processing unit (CPU) 601, a system memory 604 including random access memory (RAM) 602 and read-only memory (ROM) 603, and a system bus 605 connecting the system memory 604 and the CPU 601. Computer device 600 also includes a basic input / output system (I / O system) 606 that facilitates information transfer between various devices within the computer device, and a mass storage device 607 for storing the operating system 613, application programs 614, and other program modules 615.

[0159] The basic input / output system 606 includes a display 608 for displaying information and an input device 609 for user input, such as a mouse or keyboard. Both the display 608 and the input device 609 are connected to the central processing unit 601 via an input / output controller 610 connected to the system bus 605. The basic input / output system 606 may also include the input / output controller 610 for receiving and processing input from multiple other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 610 also provides output to a display screen, printer, or other types of output devices.

[0160] Mass storage device 607 is connected to central processing unit 601 via a mass storage controller (not shown) connected to system bus 605. Mass storage device 607 and its associated computer-readable storage media provide non-volatile storage for computer device 600. That is, mass storage device 607 may include computer-readable storage media (not shown) such as hard disk or compact disc read-only memory (CD-ROM) drive.

[0161] Without loss of generality, computer-readable storage media can include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technique for storing information such as computer-readable storage instructions, data structures, program modules, or other data. Computer storage media include RAM, ROM, erasable programmable read-only memory (EPROM), electrically-erasable programmable read-only memory (EEPROM), flash memory or other solid-state storage devices, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that computer storage media are not limited to the above-mentioned types. The system memory 604 and mass storage device 607 described above can be collectively referred to as memory.

[0162] The memory stores one or more programs, which are configured to be executed by one or more central processing units 601. The one or more programs contain instructions for implementing the above method embodiments, and the central processing unit 601 executes the one or more programs to implement the methods provided by the various method embodiments described above.

[0163] According to various embodiments of this application, computer device 600 can also be connected to and operated on a remote computer device on a network, such as the Internet. That is, computer device 600 can be connected to network 612 through network interface unit 611 connected to system bus 605, or network interface unit 611 can be used to connect to other types of networks or remote computer device systems (not shown).

[0164] The memory also includes one or more programs stored in the memory, and the one or more programs include steps performed by a computer device in the methods provided in the embodiments of this application.

[0165] This application also provides a computer-readable storage medium storing a computer program that is loaded and executed by a processor to implement the virtual level identity periodic management method provided in the above method embodiments.

[0166] This application also provides a computer program product, which includes a computer program executed by a processor to implement the virtual level identity periodic management method provided in the above-described method embodiments.

[0167] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0168] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent switching, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for periodic management of virtual level identities, characterized in that, Applied to a server, the method includes: After granting a virtual level identity to the first user, the first user's level information is divided into actual level status and displayed level identity. The actual level status is used to record the actual level identity and upgrade trajectory of the first user determined based on preset indicators, and the displayed level identity is used to record the level type currently displayed to the outside world. During the validity period of the virtual level identity, the client is controlled to display the virtual level identity in the displayed level identity, while the actual level status is continuously updated according to the behavior of the first user; When the validity period expires, the displayed level identity will be restored to the actual level identity indicated by the actual level status.

2. The method according to claim 1, characterized in that, Before granting the virtual level identity to the first user, the method further includes: At the start of each preset period, obtain a snapshot of user metrics at the end of the previous period; The identity granting object for the current period is determined from multiple users according to a preset sorting rule; The virtual level identity is granted to the identity granting object.

3. The method according to claim 2, characterized in that, The process of granting the virtual level identity to the identity granting object includes: A unique periodic version number is generated for this rating event, which includes at least one of the following: year, month, rating timestamp, and serial number; Write the classification record according to the cycle version number, and establish a unique constraint based on the cycle version number when writing; If a valid rating record already exists for the cycle version number, skip the duplicate rating and proceed to the event compensation process.

4. The method according to any one of claims 1 to 3, characterized in that, The actual level status includes at least one of the following: the user's actual level value, experience value, upgrade time, and upgrade trajectory, and the actual level identity is the current level identity determined by the first user based on the actual level status.

5. The method according to any one of claims 1 to 4, characterized in that, The displayed level identity includes at least one of the following: the validity period of the virtual level identity, the cycle version number, the default nameplate name, the nameplate name edited by the user, and the name retained in the previous cycle.

6. The method according to any one of claims 1 to 5, characterized in that, During the validity period of the virtual level identity, controlling the client to display the virtual level identity in the display level identity includes: During the validity period of the virtual level identity, the currently valid display level identity and display data version number are returned to the client, so that the client can refresh the local display data according to the display data version number and display the virtual level identity.

7. The method according to any one of claims 1 to 6, characterized in that, Maintaining the actual level status and continuously updating it based on the first user's behavior includes: During the validity period of the virtual level identity, in response to the first user's behavior data meeting the preset indicator change conditions, the actual level identity and upgrade trajectory in the actual level status are updated, and the actual level upgrade event is recorded.

8. The method according to any one of claims 1 to 7, characterized in that, The step of restoring the displayed level identity to the actual level identity indicated by the actual level status at the end of the validity period includes: Check whether the first user has any untriggered actual level upgrade events within the validity period; If it exists, an upgrade animation event and a rights reissue event corresponding to the actual level upgrade event are generated, and after the upgrade animation event and the rights reissue event are completed, the displayed level identity is switched to the actual level identity.

9. The method according to any one of claims 1 to 8, characterized in that, After granting the virtual level identity to the first user, the method further includes: Obtain the set of virtual level rights corresponding to the virtual level identity and the set of actual level rights corresponding to the actual level status; The virtual tier benefits set and the actual tier benefits set are merged according to the preset merging rules to generate a merged benefits distribution list.

10. The method according to claim 9, characterized in that, The preset merging rules include at least one of the following: For similar rights, the rights with the highest value or the largest effective scope are selected for distribution according to a preset value level or priority. Accumulate the quantity or merge the validity periods of overlapping rights; The effective rights are determined according to the preset coverage rules for mutually exclusive rights, so as to avoid lower-level rights from covering higher-level rights.

11. The method according to claim 9, characterized in that, The generation of the consolidated rights and benefits distribution list includes: Generate an idempotent key for the rights based on at least one of the following: user identifier, rights identifier, periodic version number, level source, and distribution batch; The rights in the rights distribution list are deduplicated according to the rights idempotency key, and rights with the same idempotency key that already exist in the distribution record are not distributed again.

12. The method according to any one of claims 1 to 11, characterized in that, The method further includes: At the end of the current cycle, perform the following atomic migration operations within the same transaction: If the user who was granted the virtual level identity changes, the second user's display level identity will be updated to the virtual level identity, and the second user will be the user who was granted the virtual level identity in the next cycle; Generate the virtual level upgrade animation event and the virtual level benefits distribution event for the second user; Generate a new version number for the display data and invalidate the old periodic cache.

13. The method according to claim 12, characterized in that, The method further includes: Apply optimistic locking or distributed locking to the cycle version number; When a concurrent conflict is detected, the process resumes from the breakpoint based on the cycle version number and the event execution status.

14. The method according to any one of claims 1 to 13, characterized in that, The method further includes: During the validity period of the virtual level identity, when the first user's displayed level identity is the virtual level identity, the custom nameplate editing entry permission is returned to the client corresponding to the first user; In response to the nameplate name editing request submitted by the first user through the editing entry, the system verifies whether the first user is still within the validity period of the virtual level identity, and updates the nameplate name for the current period after the verification is successful.

15. The method according to claim 14, characterized in that, The method further includes: When the first user is granted the virtual level identity in two consecutive preset periods, the nameplate name edited in the previous period is used as the historical name and entered into the nameplate editing input box of the current period. Reset the default nameplate name for the current period to the system default name.

16. The method according to any one of claims 1 to 15, characterized in that, The method further includes: When the first user undergoes an actual level upgrade within the validity period, the actual level upgrade event of the first user is obtained; In real-time mode, an actual level upgrade animation event is generated immediately, and the higher of the virtual level benefits corresponding to the virtual level identity and the actual level benefits corresponding to the actual level upgrade is distributed. In delayed mode, the actual level upgrade event and the pending benefits are recorded, and the actual level upgrade animation event and the issuance event of the pending benefits are triggered when the validity period ends.

17. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the periodic management method for virtual hierarchical identities as described in any one of claims 1 to 16.

18. A computer-readable storage medium, characterized in that, The readable storage medium stores a computer program, which is loaded and executed by a processor to implement the periodic management method for virtual hierarchical identities as described in any one of claims 1 to 16.

19. A computer program product, characterized in that, The computer program product includes a computer program executed by a processor to implement the periodic management method for virtual hierarchical identities as described in any one of claims 1 to 16.

Images