A method and apparatus for controlling display of interactive content, and related devices

Abstract

The application discloses a display control method and device of interactive content and a computer storage medium. A host page obtains activity configuration data issued by a server, sorts the activity configuration data according to display serial numbers, and removes data that does not match a directional parameter and a current running environment parameter, to obtain a target display queue; a target activity is determined according to a queue order, a routing address of the activity in an activity subapplication is determined according to a type identifier of the target activity, a loading address is obtained by splicing the routing address and display parameters; the loading address is written into an isolated container in the host page to load the activity subapplication page; an interactive message sent by the activity subapplication through a cross-document message channel is received, the interactive message is distributed and processed according to a message type after a source identifier is verified, and the next activity is dispatched when the interactive message is of a closing type until the activity is displayed completely. The method enables the activity to be online and extended without changing and redeploying the host page, and the style, script and routing of the activity side are constrained in the isolated container, and the influence on the main business process is limited.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus and related equipment for controlling the display of interactive content. Background Technology

[0002] In online business operations, interactive content such as marketing campaigns, surveys, and feature tutorials typically need to be displayed when users enter or use the main business page. Because interactive content is frequently updated, its format changes rapidly, and it usually needs to be differentiated for users in different regions, through different channels, and with different login methods, achieving flexible configuration and display of interactive content without affecting the main business operation has become a crucial requirement for these businesses.

[0003] In existing technologies, interactive content is typically developed as an integrated whole with the main application, directly integrating activity pages, styles, and interaction logic into the main application. This results in strong coupling between interactive content and the main business code. When the interactive content is adjusted, it often requires a complete rebuild and redeployment of the main application, impacting the efficiency of updating the interactive content. Furthermore, since the interactive content and the main application run in a related runtime environment, anomalies in the styles, scripts, or routes on the activity side can also affect the main business pages. In addition, as the types of interactive content increase, the main application needs to add corresponding processing logic, gradually increasing the complexity of expanding activity types and maintaining delivery rules.

[0004] Therefore, existing interactive content display methods still have shortcomings in terms of independent development and deployment, operational isolation, activity scheduling, and differentiated display. There is an urgent need for a technical solution that can reduce the coupling between interactive content and the main application, and achieve independent loading and unified display control of interactive content. Summary of the Invention

[0005] In view of the above, embodiments of this application provide a method, apparatus and computer storage medium for controlling the display of interactive content, so as to at least partially solve the above problems.

[0006] In a first aspect, embodiments of this application provide a method for controlling the display of interactive content, applied to a host page, the method comprising: Obtain activity configuration data sent by the server, the activity configuration data including the activity's display sequence number, targeting parameters, type identifier, and display parameters; The activity configuration data is sorted according to the display sequence number to obtain a display queue. Activity configuration data in the display queue whose orientation parameters do not match the current running environment parameters of the host page are removed to obtain the target display queue. The target activity is determined according to the order of the target display queue. The route address corresponding to the target activity in the activity sub-application is determined according to the type identifier of the target activity. The route address is then concatenated with the display parameters of the target activity to obtain the loading address of the target activity. The activity sub-application and the host page are independently managed, built, and deployed. The loading address is written into the isolation container in the host page, and the isolation container loads the active sub-application page pointed to by the loading address. The isolation container is used to isolate the active sub-application page from the host page in terms of document object model, style scope, script context and routing. Receive the interactive message sent by the activity sub-application through the cross-document message channel, verify the source identifier carried by the interactive message, and distribute the interactive message according to the message type of the verified interactive message; Specifically, when the message type is closed, the next activity in the target display queue is determined as the new target activity, and the display continues according to the new target activity until all activities in the target display queue have been displayed.

[0007] Secondly, based on the interactive content display control method described in the first aspect of this application, embodiments of this application also provide an interactive content display control device, comprising: The configuration acquisition module is used to acquire the activity configuration data sent by the server. The activity configuration data includes the activity's display sequence number, targeting parameters, type identifier, and display parameters. The scheduling and filtering module is used to sort the activity configuration data according to the display sequence number to obtain a display queue, and to remove the activity configuration data in the display queue whose orientation parameters do not match the current running environment parameters of the host page to obtain a target display queue. A loading control module is used to determine the target activity according to the order of the target display queue, determine the routing address corresponding to the target activity in the activity sub-application based on the type identifier of the target activity, concatenate the routing address with the display parameters of the target activity to obtain the loading address of the target activity, and write the loading address into an isolation container in the host page. The isolation container then loads the activity sub-application page pointed to by the loading address. The activity sub-application and the host page are independently managed, built, and deployed. The isolation container is used to isolate the activity sub-application page from the host page in terms of document object model, style scope, script context, and routing. The message processing module is used to receive interactive messages sent by the activity sub-application through a cross-document message channel, verify the source identifier carried by the interactive message, and distribute the message according to the message type of the verified interactive message; wherein, when the message type is a closed type, the next activity in the target display queue is determined as the new target activity, and the display continues according to the new target activity until all activities in the target display queue have been displayed.

[0008] Thirdly, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, perform any of the interactive content display control methods described in the first aspect of embodiments of this application.

[0009] The interactive content display control method, device, and computer storage medium provided in this application decentralize the page rendering and interactive logic of the activity to an activity sub-application that is independently managed, built, and deployed from the host page. The host page only retains the loading scheduling and message relay of the activity. The launch, modification, and expansion of new forms of the activity are all handled by the activity configuration data issued by the server and the routing of the activity sub-application itself, without the need to modify and redeploy the host page. At the same time, the document nodes, style rules, script context, and route jumps on the activity side are constrained within an isolated container, thereby reducing the possibility of activity operation abnormalities affecting the main business process. In addition, the host page completes sequential scheduling and targeted filtering based on the display sequence number and targeting parameters, so that the scope of interactive content delivery and display rhythm can be finely controlled without modifying the code. Attached Figure Description

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

[0011] Figure 1 A schematic diagram illustrating the workflow of an interactive content display control method provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the workflow of another interactive content display control method provided in this application embodiment; Figure 3 An exemplary workflow diagram of an interactive content display control method provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of an interactive content display control device provided in an embodiment of this application; Figure 5 This is a schematic diagram of a layered architecture of a host page and active sub-applications provided in an embodiment of this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions in the embodiments 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. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of this application.

[0013] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0014] Example 1 This application provides a method for controlling the display of interactive content, which is applied to a host page, such as... Figure 1 As shown, Figure 1 This illustration shows a flowchart of an interactive content display control method provided in an embodiment of this application, including: Step S101: Obtain the activity configuration data sent by the server. The activity configuration data includes the activity's display sequence number, targeting parameters, type identifier, and display parameters.

[0015] To facilitate understanding of the implementation process of the method described in this application embodiment, the following explanations are provided for some terms used in this embodiment. The host page in this application embodiment refers to the application page that carries the main business process, i.e., the page where the user actually handles business and uses the main functions. In the method described in this application embodiment, the host page is only responsible for loading and scheduling activities, lifecycle management, and message relay; it does not carry any activity's business logic itself. The interactive content in this application embodiment refers to marketing activities, questionnaires, function guides, etc., presented to the user in the form of pop-ups, superimposed on the main business process. For ease of description, these are collectively referred to as "activities" below. The activity sub-application in this application embodiment refers to an independent front-end project that carries the entire activity page structure, style rules, and interactive logic. It has an independent code library, an independent build process, and an independent deployment environment. It does not share code with the host page; the two only communicate through address and message channels. The activity configuration data described in this application embodiment is a set of structured data used by the server to describe who sees an activity, in what order they are seen, what they are seen, and in what form they are seen. It includes at least display sequence number, orientation parameters, type identifier, and display parameters, and may further include fields such as activity identifier, effective start and end time, floating attributes, and button configuration information. This application embodiment does not limit the specific number and naming method of the fields it contains.

[0016] The reason this step externalizes all variable parts of the activity into data distributed by the server is because the activity itself has inherent attributes such as variable content, rapid launch, and detailed delivery rules. If the timing, scope, order, and materials for the activity's display are hardcoded into the host page's code, then any adjustment on the operations side will translate into a code modification and redeployment of the host page, which is the direct source of the defects described in the background technology. Therefore, this embodiment of the application unifies these variable parts into activity configuration data, allowing the host page to act only as a consumer of data rather than a holder of rules.

[0017] In practice, the host page calls the server-side interface once to retrieve all activity configuration data visible to the current user at any given time and cache it in memory. Subsequent sorting, filtering, loading, and scheduling processes are all based on this data, eliminating the need for repeated requests. In a typical implementation scenario, this request can be executed in the callback logic after the user successfully logs in. This ensures that the inputs required for targeted filtering, such as region, channel, and login method, are fully determined at this point, while also merging a single network request into the login process. It should be noted that this embodiment does not limit the specific triggering time for obtaining activity configuration data. The host page can also obtain the aforementioned data upon its own initialization, upon entering a designated main business page, or upon receiving a push notification from the server. Through this step, the launch, modification, and decommissioning of activities can all be accomplished by the server modifying the activity configuration data, while the host page code remains unchanged. This allows the operations team to independently release activities outside the main application's release cycle, and also provides a complete data foundation for scheduling multiple activities at a unified pace in the next step.

[0018] Step S102: Sort the activity configuration data according to the display sequence number to obtain the display queue, and remove the activity configuration data in the display queue whose orientation parameters do not match the current running environment parameters of the host page to obtain the target display queue.

[0019] The display sequence number mentioned in this application embodiment is a value in the activity configuration data used to indicate the order in which the activity is displayed among multiple activities; the orientation parameter is a set of constraints in the activity configuration data used to describe the scope of the activity's deployment; the runtime environment parameter is a set of context values ​​of the host page in the current session, which corresponds one-to-one with the orientation parameter and is the comparison benchmark for determining whether the current user falls within the scope of a certain activity's deployment.

[0020] The reason for prioritizing sorting before filtering in this step is to ensure that the display order is determined solely by the display sequence number configured on the server side, and is unaffected by the filtering results. First, all activity configuration data is organized into an ordered display queue based on the display sequence number. Then, activities that do not meet the deployment conditions are removed one by one. The relative order of the remaining activities is completely consistent with the server's configuration intent. If the order is reversed, the stability of the queue will depend on the implementation details of the filtering, making it difficult for the operations team to predict the display rhythm based solely on the display sequence number. In practice, the host page sorts the activity configuration data in ascending order using the display sequence number as the key to obtain the display queue. Then, a targeting judgment is performed item by item, comparing the targeting parameters with the runtime environment parameters. If any mismatch exists, the activity configuration data is removed. The remaining activity configuration data forms the target display queue in its original order. It should be noted that, in an optional implementation of this application embodiment, the host page may further update the target display queue based on the do-not-disturb state after obtaining the target display queue, and remove the activities that the user has previously selected not to remind again; wherein, the do-not-remind operation selected by the user on the activity page corresponds to the do-not-disturb state described in this application embodiment. For ease of description, the do-not-disturb state will be used to refer to this record in the following text, and the specific process will be explained later.

[0021] Through this step, the delivery rules are extracted from the code branch of the host page, turning into a pure data comparison: changing the delivery scope only requires changing the targeting parameters sent by the server, and changing the display rhythm only requires changing the display sequence number. This logic of the host page remains unchanged, thus achieving differentiated display and clarifying a unique and orderly source of objects to be displayed for subsequent steps.

[0022] Step S103: Determine the target activity according to the order of the target display queue, determine the routing address corresponding to the target activity in the activity sub-application according to the type identifier of the target activity, and concatenate the routing address with the display parameters of the target activity to obtain the loading address of the target activity; wherein, the activity sub-application and the host page are independently managed, built and deployed.

[0023] The type identifier mentioned in this application embodiment is a field in the activity configuration data used to indicate the presentation form of the activity; the routing address refers to the path used to uniquely locate a specific activity page within the activity sub-application, which is defined and maintained by the activity sub-application itself; the display parameters refer to the variable data required for the activity during rendering, such as image addresses, jump links, scene identifiers, etc.; the loading address is the complete access address that the host page is finally written into the isolation container, which is composed of the access address of the activity sub-application, the routing address, and the display parameters.

[0024] The reason this step places the mapping relationship from type to page within the activity sub-application, while only retaining a single concatenation of the type identifier to the route address on the host page, is to ensure that the expansion of activity forms no longer affects the host page. In traditional technical solutions, for each new activity form, the main application needs to add a decision branch and a rendering implementation, with the expansion cost accumulating with the number of types. However, in this embodiment, the host page's only knowledge of the activity form is the type identifier field. It doesn't know how to render the image or what interactions are in the scene page; it simply retrieves the route address based on the identifier and concatenates it with the display parameters. In the specific implementation, the host page retrieves an activity configuration data entry from the head of the target display queue as the target activity, reads its type identifier, determines its route address in the activity sub-application according to the pre-agreed correspondence, and then appends the display parameters to the route address as query parameters to obtain the loading address. This correspondence is a simple mapping between identifier and path, which can also be sent by the server along with the activity configuration data. Therefore, when adding a new activity form, only a route and a page component need to be added in the activity sub-application, and a mapping needs to be added on the server side; the host page code remains unchanged.

[0025] Through this step, the expansion of activity types is restricted to the activity sub-application side. The host page remains unaware of the new types, and the expansion cost no longer accumulates with the increase of activity types. At the same time, since the variable data required for display is passed along with the loading address, this also creates the conditions for the next step to use a unified container to hold activity pages of all types.

[0026] Step S104: Write the loading address into the isolation container in the host page, and load the active sub-application page pointed to by the loading address by the isolation container. The isolation container is used to isolate the active sub-application page from the host page in terms of document object model, style scope, script context and routing.

[0027] The isolated container described in this application refers to a container embedded within a host page document, used to independently load and render another page document. The browser creates a separate runtime environment for the document within the container. In one optional implementation, the isolated container can be implemented using an embedded frame. The document object model refers to the tree structure created by the browser for a page document, describing page elements and their hierarchical relationships in the form of nodes. The style scope refers to the range of elements to which a style rule can actually take effect. The script context refers to the scope of the global object to which a script code is attached, as well as its variables, timers, and exception handling. The routing refers to the mechanism by which a page switches between different views based on address changes.

[0028] The reason for choosing to host the active sub-application page in this step is that the instability mentioned in the background technology essentially stems from the fact that the active code and the main business code run in an interconnected runtime environment. This application embodiment severs this connection in four aspects through the isolation container: First, the active sub-application pages within the container have independent document object models. Their node identifiers, hierarchical relationships, and event bubbling paths are all independent of the host page, so there will be no situation where active elements and main business elements compete for the same node identifier or cover each other. Secondly, the style rules within the container have independent style scope, and global selectors written on the activity side will not overwrite existing buttons, forms, and layouts on the main business page. Third, the scripts within the container run in an independent script context. The global variables registered by the active script, the timers it uses, and even the uncaught exceptions it throws are all confined within the container, thus limiting its direct impact on the host page's runtime environment. Fourth, the active sub-applications within the container have independent routes. Their view switching within the container will not be written to the routing state and browsing history of the host page. After the user jumps multiple times within the activity and triggers the browser's back operation, they will still return to the original main business page.

[0029] In the specific implementation process, the host page places an isolation container within its layout container and assigns the loading address obtained in step S103 to the address attribute of the isolation container. The browser then requests and renders the activity sub-application page pointed to by that address. When the activity ends, the host page clears or destroys the isolation container, and the nodes, styles, scripts, and timers occupied by the document within the container are released accordingly. It should be noted that this application embodiment does not limit the respective running carriers, building tools, and deployment forms of the host page and the activity sub-application, as long as they can be built and deployed independently. Through this step, the running traces on the activity side are constrained within the boundaries of the isolation container. Even if an activity page has defects or cannot be rendered normally, its impact is mainly limited to the container itself, thereby reducing the possibility of activity running abnormalities affecting the main business process. At the same time, since the activity sub-application is loaded in the form of a complete page document, it can retain its own building artifacts and deployment environment, which is the technical premise for the activity to be published independently of the host page.

[0030] Step S105: Receive the interaction message sent by the activity sub-application through the cross-document message channel, verify the source identifier carried by the interaction message, and distribute the interaction message according to the message type of the verified interaction message; wherein, when the message type is the closed type, determine the next activity in the target display queue as the new target activity, and continue to display according to the new target activity until all activities in the target display queue have been displayed.

[0031] The cross-document message channel described in this application refers to a communication mechanism provided by a browser that allows the transmission of structured data between two windows with different document contexts. The interactive message refers to a piece of structured data delivered by an active sub-application to the host page through this channel after a user operation, which includes at least two fields: source identifier and message type. The source identifier is a fixed field agreed upon in the message body, used to indicate that the message was indeed sent by the active sub-application as defined in this solution. The message type is used to indicate what kind of processing the host page should perform for this message.

[0032] While isolation containers provide isolation capabilities, they also open a cross-document pathway to the host page. Third-party scripts within the same browser window and other embedded pages can also send messages to the host page. If the host page executes the received messages indiscriminately, it exposes the main business's navigation and API call capabilities to any source. Therefore, this application's embodiments stipulate that all interactive messages must carry a source identifier. The host page first retrieves this field in the global message listener and compares it with a preset value. Messages that do not match are directly discarded without any further processing, thereby preserving cross-document communication capabilities while bringing externally triggered entry points back into a controlled scope.

[0033] In the specific implementation of this application embodiment, the host page registers a global message listener during initialization. For each arriving interaction message, the source identifier is first verified. If the verification passes, the message type is read and distributed to the corresponding processing logic. Specifically, when the message type is "closed," it indicates that the current activity's display has ended. The host page determines the next activity in the target display queue as the new target activity and re-executes steps S103 and S104. This process is repeated until all activities in the target display queue have been displayed. Besides the "closed" message type, the host page can also handle other message types such as "do not disturb," "resource request," and "content click" using the same distribution method. The specific processing procedures will be described later.

[0034] Through this step, a unified and verifiable bidirectional pathway is established between the host page and the activity sub-applications: the activity sub-applications cannot directly access the internal state of the host page, and all their requests are standardized as interactive messages with source identifiers; the host page also does not need to know the internal interactive details of the activity page, but only performs a limited number of actions based on the message type. At the same time, the cycle of loading, interacting, closing, and reloading is uniformly driven by the host page, so multiple activities are presented sequentially according to the order configured on the server side, and there will be no situation where multiple pop-ups occupy the screen at the same time. Thus, steps S101 to S105 constitute a complete closed loop from data acquisition to the end of display.

[0035] Optionally, in one implementation of this application embodiment, the targeting parameters include a region code, a channel code, and a login method identifier. Correspondingly, the process of removing activity configuration data that does not match the targeting parameters and operating environment parameters includes: comparing the region code, channel code, and login method identifier in the activity configuration data with the region code, channel code, and login method identifier currently belonging to the host page, respectively. If any item in the comparison result does not match, the corresponding activity configuration data is removed from the display queue. This application embodiment defines the delivery scope from three dimensions because the differentiated display requirements of the operation side usually unfold along these three dimensions: the region code is used to distinguish users in different regions, so that regional activities are only visible to users in that region; the channel code is used to distinguish which distribution channel a user enters the application through; and the login method identifier is used to distinguish the method used for this login, so that activities that are only meaningful to a certain type of account system are only visible to users who log in using that method. The three dimensions adopt a conjunction relationship that is satisfied simultaneously. The operations side can fill in only one of them for coarse-grained targeting, or fill in all three for fine-grained targeting. The host page does not need to prepare different judgment branches for different targeting granularities. Therefore, the adjustment of the display range is entirely based on the targeting parameters issued by the server.

[0036] Optionally, in one implementation of this application embodiment, the type identifier includes image display type, link jump type, and custom scene type. Correspondingly, the process of determining the route address and loading address includes: when the type identifier is image display type, determining the image display route in the activity sub-application as the route address, and concatenating the image address of the target activity as a display parameter into the query parameters of the route address; when the type identifier is link jump type, determining the link carrying route in the activity sub-application as the route address, and concatenating the jump link and opening method parameter of the target activity as display parameters into the query parameters of the route address, so that the activity sub-application loads the jump link in the manner indicated by the opening method parameter, such as opening in a new window, opening in the current page, or opening within an isolated container; when the type identifier is custom scene type, determining the scene route corresponding to the scene identifier of the target activity in the activity sub-application as the route address, and concatenating the scene identifier as a display parameter into the route address.

[0037] The three types of identifiers listed in this embodiment correspond to the three most commonly used activity formats on the operations side. Their requirements for the activity sub-applications increase sequentially, thus forming a path that can be expanded step by step. Image display is the lightest format; the activity content itself is an image. Therefore, only the image address needs to be passed as a display parameter, and the image display route in the activity sub-application is responsible for retrieving the parameter and rendering. Changing an activity image only requires replacing the image address on the server side; neither the activity sub-application nor the host page needs to be republished. Link jump is for scenarios where the activity content is located on another existing page. In this case, the activity sub-application only undertakes the responsibility of hosting and opening. Whether it opens in a new window, on the current page, or embedded in an isolated container is determined by the opening method parameter, eliminating the need to write a separate implementation for each jump experience. Custom scenario is for activities requiring independent interactive logic, such as questionnaires or step-by-step guidance. In this case, the scenario identifier is used as a routing parameter, mapping to the corresponding scenario page in the activity sub-application. Each scenario corresponds to an independent page component and route. Therefore, when a new activity scenario is added, the changes are restricted to the activity sub-application. All the host page needs to do is issue a new scenario identifier, thus resolving the issue mentioned in the background technology that the main application needs to add processing logic synchronously when expanding the activity type.

[0038] Furthermore, in an optional implementation of this application embodiment, the method may further include: determining the target display width of the isolation container based on the type identifier of the target activity, wherein different type identifiers correspond to different target display widths; assigning the target display width to the style variable of the layout container carrying the isolation container, and having the layout container adjust the rendering width of the isolation container according to the value of the style variable. The style variable mentioned in this application embodiment refers to a variable declared in a style sheet, whose value can be dynamically rewritten by a script, and whose style rules can be referenced and read in real time. The reason for adjusting the width according to the type identifier is that different types of activities have very different requirements for display area: image display types only require a standard size proportional to the image ratio, custom scene types often contain more elements such as forms and step-by-step content and require a larger size, while activities with resources such as QR codes as their main content require a size adapted to the resources. Since the document inside the container is isolated from the host page, the host page cannot directly read the content size inside the container. Therefore, the approach of determining the width based on the type identifier outside the container avoids penetrating the isolation boundary, fully preserving the isolation relationship established in step S104, and enabling the same isolation container to adaptively carry activity pages of different types.

[0039] Optionally, in one implementation of this application, the process of obtaining the loading address of the target activity includes: obtaining the current runtime environment identifier of the host page, and determining the basic access address of the activity sub-application corresponding to the runtime environment identifier; concatenating the basic access address, the routing address represented in hash routing form, and the display parameters in sequence to obtain the loading address of the target activity; wherein, the hash routing is a routing form in which the hash symbol in the address and the characters following the hash symbol represent the page routing, and the routing state of the host page is not changed when the activity sub-application performs routing jumps within the isolated container. The runtime environment identifier mentioned in this application refers to a value used to distinguish the current development environment, testing environment, or production environment of the host page; the basic access address is the access address prefix deployed by the activity sub-application in the corresponding environment, such as the access address prefix corresponding to the development environment, production environment, or other preset runtime environments.

[0040] This embodiment further defines the process of concatenating the loading address to address a related problem arising from independent deployment: since the activity sub-application and the host page are deployed separately, their access addresses are independent of each other, and the same set of host page code needs to run in multiple preset runtime environments such as development and production. If the access address of the activity sub-application is hardcoded, a host page build artifact must be maintained for each environment. Therefore, this embodiment allows the host page to dynamically select the corresponding basic access address based on its own runtime environment identifier, so that the same set of code can be smoothly migrated between multiple environments. The use of hash routing to carry the routing address ensures that the view switching of the activity sub-application within the isolated container only changes the part after the hash symbol in the address. The browser will not initiate a new document request to the server, and the routing status and browsing history of the host page will not be changed by the jump within the container. This is consistent with the routing isolation described in step S104, and together they ensure that multi-level jumps within the activity will not interfere with the user's forward and backward movement in the main business process.

[0041] Optionally, in one implementation of this application embodiment, the process of distributing processing according to message type further includes: when the message type is a resource request type, the host page calls the server interface to obtain the resource data indicated by the resource request type, and returns the resource data to the activity sub-application in the form of a callback message through the cross-document message channel, so that the activity sub-application can render according to the resource data; when the message type is a content click type, the host page performs jump processing according to the jump parameters carried in the interaction message. The two message types added here in this application embodiment deal with two situations where the activity page needs to rely on the capabilities of the host page. The first is that the activity page needs to display resources that can only be obtained by a logged-in session, such as a QR code image bound to the current user: the activity sub-application runs in an isolated container and does not hold the login session of the host page. It is neither feasible nor safe for it to directly request the server. Therefore, it sends an interaction message of the resource request type, and the host page calls the server interface on its behalf and returns the resource data in the form of a callback message. The second scenario involves a user clicking on event content and expecting to be redirected to a specific location within the main business logic. The event page resides within an isolated container, and its own redirection only alters the document within the container. Therefore, it sends a content click-type interaction message carrying redirection parameters, and the host page completes the redirection outside the container. Both types of processing follow the same principle: any action that touches upon the main business capabilities must go through the host page and pass source identifier verification first. This ensures that the functional requirements of the event page are met while preventing the host page's session and redirection capabilities from being transferred to the container.

[0042] Optionally, in one implementation of this application embodiment, the activity configuration data further includes an activity identifier; the method further includes: when the message type is a do-not-disturb type, writing the activity identifier of the target activity and the corresponding do-not-disturb status into the storage layer corresponding to the do-not-disturb type, wherein the do-not-disturb type includes valid for the current day, valid for seven days, valid for the current month, permanently valid, and permanently valid across devices. Specifically, when the do-not-disturb type is valid for the current day, valid for seven days, valid for the current month, or permanently valid, the activity identifier of the target activity and the corresponding do-not-disturb status are written into the local storage of the browser where the host page is located; when the do-not-disturb type is permanently valid across devices, the do-not-disturb status of the target activity is written into the server's key-value cache through the server-side interface, wherein the cache key of the key-value cache is generated by combining the activity identifier of the target activity and the user identifier of the current user. The "Do Not Disturb" state described in this application refers to a marker recorded after a user actively chooses not to be reminded again during the display process, indicating that the corresponding activity should not be displayed to the user again within its validity period; the storage hierarchy refers to several storage locations on the host page used to record the "Do Not Disturb" state, with different storage locations corresponding to different retention durations and effective ranges; the local storage refers to a storage area provided by the browser that can store a small amount of key-value data for a long time within the same browser; the key-value cache refers to a caching service on the server side that stores a small amount of state data in a key-value manner.

[0043] This application embodiment divides the Do Not Disturb state into five levels and places them in different storage locations because the user's intention to no longer receive reminders varies in strength, and different strengths of intention have different requirements for retention duration and scope of effectiveness. The three types of valid for the day, valid for seven days, and valid for the month express that the user does not want to view the activity for the time being. When writing the activity, the host page can record the expiration timestamp corresponding to the validity period. When reading the activity, if the current time is later than the timestamp, the record is no longer valid, and the activity will be displayed again without server intervention. Permanently valid means that the user does not want to view the activity on this device. The activity is written to local storage and no expiration time is set. Permanently valid across devices means that the user does not want to view the activity again. If the activity is still recorded locally in the browser, the record will be lost when the user changes devices or clears browser data, and the activity will reappear. Therefore, this level is written to the key-value cache on the server and a cache key is generated by combining the activity identifier and the user identifier, so that the record follows the user rather than the device. In a typical configuration, interactive controls for image-based activities usually offer four types of do-not-disturb options written to the browser's local storage: valid for the day, valid for seven days, valid for the month, and valid indefinitely. Custom-based activities, on the other hand, because their content usually requires users to participate fully once, typically offer a do-not-disturb option of being valid across devices indefinitely, written to the server's key-value cache, to ensure that the blocking results are consistent across devices.

[0044] Correspondingly, after obtaining the target display queue, the system also reads the active "Do Not Disturb" statuses from local storage and the server's key-value cache, and removes the activity configuration data with recorded "Do Not Disturb" statuses from the target display queue to obtain an updated target display queue. Subsequent activities are then determined according to the order of this updated target display queue. The reason "Do Not Disturb" filtering is placed after the target display queue is formed, rather than mixed with targeted filtering, is because they are different in nature: targeted filtering determines whether an activity should be shown to a user, and its result determines the user's set of visible activities; "Do Not Disturb" filtering determines whether the activity should pop up again at this moment, only affecting the current pop-up rhythm. By separating the two, the set of visible activities and the current pop-up set become two clearly defined intermediate results. The persistent activities discussed later are selected from the former, thus avoiding the situation where users are shown activity entries that are not actually visible. At the same time, the records on both the local and server sides are merged into a unified judgment criterion, making the aforementioned five levels completely equivalent to the upper-level scheduling logic; the write and read ends are thus connected end to end: the user's "do not remind again" option is written to the corresponding storage level via an interactive message, and is read back and converted into a removal when step S102 is executed next time.

[0045] Optionally, in one implementation of this application embodiment, the activity configuration data further includes a floating attribute, such as... Figure 2 As shown, Figure 2 A schematic diagram of the workflow of another interactive content display control method provided in this application embodiment, the method further includes steps S106 and S107 based on steps S101 to S105: Step S106: After all activities in the updated target display queue have been displayed, determine the last activity with the floating attribute enabled from the target display queue according to the display sequence number, designate the determined activity as a permanent activity, and display the floating entry control corresponding to the permanent activity on the host page.

[0046] Step S107: In response to the trigger operation of the floating entry control, a forced display flag is set, and when the forced display flag is valid, the do-not-disturb state recorded by the persistent activity is ignored, the routing address corresponding to the persistent activity is re-determined, the routing address is concatenated with the display parameters of the persistent activity to obtain the loading address of the persistent activity, and the loading address is written into the isolation container to reload the activity sub-application page corresponding to the persistent activity.

[0047] The floating attribute described in this application embodiment is a switch field in the activity configuration data used to indicate whether the activity needs to retain a persistent entry point after the pop-up display ends. The floating entry point control refers to a small-sized control that remains on the host page after the pop-up is closed, allowing the user to actively reopen the activity. The forced display flag is a temporary marker set by the host page during this reopening process to indicate that the do-not-disturb judgment should be skipped during this loading. The reason for selecting the last activity with the floating attribute enabled according to the display sequence number is that only one floating entry point is retained on the page, and the display sequence number itself represents the priority order of the server-side configuration. Taking the last one in the sequence number allows the newly configured persistent activity to overwrite the previous persistent activity. The operations side only needs to add a new activity configuration data entry with the floating attribute enabled to complete the entry point replacement without having to take the original configuration offline first. The reason for selecting the target display queue instead of all activity configuration data is that the target display queue has already undergone targeted filtering but has not yet been affected by the Do Not Disturb state. Using this queue ensures that persistent activities always remain within the current user's visibility range, preventing the display of entry points for activities outside its scope. Simultaneously, it prevents the entry point from disappearing simply because the user previously selected "Do Not Disturb," echoing the handling of the forced display flag ignoring the Do Not Disturb state described below. Furthermore, this step addresses a side effect of the Do Not Disturb filtering: once a user selects "Do Not Disturb," they can no longer return to the activity via a pop-up. However, long-standing activity entry points should not be permanently blocked by historical selections. Therefore, passive display and active entry are distinguished. The former remains constrained by the Do Not Disturb state, while the latter bypasses this constraint through the forced display flag. This preserves the protection of the Do Not Disturb mechanism for users while providing a persistent and controllable entry point for long-term activities.

[0048] Furthermore, in an optional implementation of this application embodiment, the process of responding to a trigger operation on the floating entry control may further include: listening to press events, move events, and release events acting on the floating entry control; after listening to a press event, if the displacement corresponding to the move event is greater than a preset displacement threshold, then setting the drag flag, updating the display position of the floating entry control on the host page according to the position of the move event, and constraining the updated display position within the boundary range of the current visible area; when listening to a release event, if the drag flag is not set, then the current operation is determined to be a trigger operation on the floating entry control, and the drag flag is reset. This addresses two problems caused by the floating entry control remaining on the page for a long time: first, the control may press down on the area that the user needs to operate on, so the user must be allowed to move it away; second, once movement is allowed, the press and release operations simultaneously have the meanings of dragging and clicking, and if not distinguished, each movement will mistakenly trigger a reopening. By using a preset displacement threshold as a criterion and resetting the drag flag after each lift, the judgment of the next operation is not affected by the current one. Constraining the display position within the visible area prevents the control from being lost after being dragged off-screen. Furthermore, the floating entry control supports both collapsed and expanded modes. In collapsed mode, it occupies only a small portion of the page area, further reducing its obstruction of the main business page.

[0049] Optionally, in one implementation of this application embodiment, after writing the loading address into the isolation container, the method further includes: after listening to the loading completion event of the isolation container, sending a configuration message to the activity sub-application through a cross-document message channel. This configuration message carries the source identifier of the host page and the button configuration information of the target activity. The button configuration information includes the display text of the interactive control and the corresponding do-not-disturb type of the interactive control, so that the activity sub-application can render the interactive control according to the button configuration information. This application embodiment here defines the direction from the host page to the activity sub-application on the cross-document message channel. The reason for setting this direction is that the text of the interactive control and its optional do-not-disturb types are essentially operational configurations. The same activity may only provide one do-not-disturb type at different deployment stages, or it may provide multiple types simultaneously. If these options are hardcoded into the activity sub-application's page, the activity sub-application must be republished every time adjustments are made, thus weakening the benefits of independent deployment. Therefore, after the container finishes loading, the host page forwards the button configuration information, which is sent along with the activity configuration data, to the activity sub-application via a configuration message. The sub-application then renders the interactive controls accordingly. Since the "Do Not Disturb" type subsequently returned by the activity sub-application is the same value sent by the host page, the understanding of the "Do Not Disturb" type on both sides is naturally consistent. It should be noted that this configuration message also carries a source identifier, which the activity sub-application uses to verify the message source, making this path verifiable in both directions.

[0050] For ease of understanding, this application provides an exemplary description of the above method in conjunction with a complete demonstration process. For example... Figure 3 As shown, Figure 3 This is an exemplary workflow diagram of an interactive content display control method provided in this application embodiment. After a user logs in, the host page obtains activity configuration data from the server, sorts the activity configuration data according to the display sequence number, filters it according to the targeting parameters to obtain the target display queue, and then updates the target display queue according to the do-not-disturb state. Next, it checks whether the updated target display queue is empty. If it is not empty, the activity at the head of the queue is taken as the target activity, the corresponding activity sub-application page is loaded according to the type identifier, and after the user's operation, the interaction message is received and the source identifier is verified. The do-not-disturb state is written to the corresponding storage layer, and then the next activity in the updated target display queue is scheduled, returning to the check of whether the queue is empty. If the queue is empty, the last activity with the floating attribute enabled is identified, the floating entry control is displayed, and the current pop-up is closed.

[0051] For example, suppose the server sends out four activity configuration data entries, numbered one through four: the first is an image-based activity targeting region A and channel B; the second is a custom scenario-based questionnaire activity with no limited reach; the third is a link-based activity targeting region C; and the fourth is a link-based activity targeting region A with its floating attribute enabled. If the current user is in region A and channel B, the third activity will be removed during the targeting filtering stage due to a region code mismatch, while the first, second, and fourth activities will be retained in the target display queue. The host page first displays the first activity. When the user selects "Don't remind me again for the rest of the day," the host page writes the activity's identifier and corresponding "Do Not Disturb" status to local storage and displays the second activity. After the user submits the questionnaire and closes the pop-up, the host page continues displaying the fourth activity. Once the fourth activity is closed, the updated target display queue is empty. The host page then identifies the last activity with the floating attribute enabled (the fourth activity) from the target display queue and displays its floating entry control. Subsequently, when the user actively clicks this control, the host page sets a forced display flag and reloads the activity, regardless of whether it was previously recorded as "Do Not Disturb." As for the third activity, since it was removed during the targeted filtering phase, it will neither be displayed nor become a permanent activity. Throughout this process, the host page code does not contain the name of any specific activity; all differences stem from the activity configuration data sent by the server and the routing within the activity sub-application.

[0052] Furthermore, in an optional implementation of this application embodiment, the method may further include degradation processing in case of loading exception: the host page starts a loading timer while writing the loading address into the isolation container. If no ready message is received from the activity sub-application within a preset loading time, the loading is determined to be abnormal. The host page destroys the isolation container, skips the current target activity, and directly identifies the next activity in the target display queue as the new target activity for continued display. At the same time, it reports exception information containing the activity identifier, loading address, and failure time of the target activity through the server interface. This processing is added here to extend the consideration of reducing the impact on the main business process from the spatial dimension to the temporal dimension: the isolation container has already limited the impact of activity defects on the main business operating environment, but if an activity sub-application page cannot complete rendering for a long time due to a release accident, network anomaly, or script error, the isolation container will still remain on the screen as a blank pop-up, and the entire display queue will stop. After introducing loading timer and degradation skipping, the user only perceives that this activity has been skipped; the reported exception information allows the operation and development sides to quickly locate the problematic activity based on the activity identifier.

[0053] Furthermore, in an optional implementation of this application embodiment, the method may further include feedback of display effects: when the host page successfully loads the activity sub-application page, when it receives a content click-type interaction message, and when it receives a close-type interaction message, it respectively sends back exposure records, click records, and close records carrying activity identifiers through the server interface; the server calculates the exposure volume and click-through rate of each activity based on the returned records, and adjusts the display sequence number of each activity accordingly when issuing activity configuration data later. This process is added here because the determination of the display order still relies on the subjective judgment of the operators, lacking feedback from the actual display results. The host page is on the necessary path of activity display and user interaction, and already knows the three moments of loading completion, content click, and close. Its return of records requires neither the cooperation of the activity sub-application nor the addition of new tracking paths; the server uses this to prioritize activities with higher click-through rates and postpone activities with long-term no clicks, making the display sequence number a parameter that can be continuously adjusted based on the effect, rather than a static configuration.

[0054] This application also exemplarily illustrates the hierarchical relationship between the host page and active sub-applications involved in the above-described method. For example... Figure 5 As shown, Figure 5This is a schematic diagram of a layered architecture for a host page and an activity sub-application provided in an embodiment of this application. The host page side includes a layout container, a pop-up scheduler, a targeting filter unit, an isolation container, a floating entry control, and a server-side interface unit. The layout container houses the isolation container. The pop-up scheduler drives a loop of loading, interacting, closing, and reloading according to the order of the target display queue. The targeting filter unit performs filtering of targeting parameters and do-not-disturb states. The server-side interface unit is responsible for obtaining activity configuration data, reading and writing the server's key-value cache, and requesting resource data on behalf of the activity sub-application. A cross-document message channel handles bidirectional message transmission between the two, carrying source identifiers. The activity sub-application side includes a front-end routing and distribution unit, as well as image display pages, link-to-link pages, and custom scene pages, each with its own independent codebase, independent construction, and independent deployment. The two are separated by an isolation boundary. The host page's entire effect on the activity sub-application is through a single loading address, and the activity sub-application's entire effect on the host page is through a single interaction message with a source identifier. It should be noted that... Figure 5 The unit division shown is merely an exemplary division for ease of explanation and does not constitute a limitation on the implementation of the method described in this application.

[0055] Compared to the methods described in the background art, the methods in this application differ mainly in three aspects. First, the activity's page and overall logic reside within an independently built and deployed activity sub-application. The host page references it only through a single loading address, thus the activity's release is no longer constrained by the main application's release cycle. Second, the activity sub-application page and the host page are isolated from each other in terms of document object model, style scope, script context, and routing. Style out-of-bounds errors, global variable pollution, uncaught exceptions, and route contention on the activity side are all confined within the container boundary, thus limiting their direct impact on the main business page. Third, all exchanges between the two are standardized as interactive messages carrying source identifiers. The host page verifies the source of each message before distributing it by type, preserving necessary collaboration capabilities while ensuring that externally triggered entry points remain within a controlled scope.

[0056] In summary, the interactive content display control method described in this application's embodiments sinks the entire page rendering and interactive logic of the activity into an independently deployed activity sub-application. The host page only retains scheduling and message relay. The launch, modification, and expansion of new forms of the activity do not require modification and redeployment of the host page. The document nodes, style rules, script context, and route jumps on the activity side are constrained within an isolated container, thereby reducing the possibility of activity operation abnormalities affecting the main business process. At the same time, sequential scheduling and targeted filtering are completed based on the display sequence number and targeting parameters, so that the scope of interactive content delivery and display rhythm can be finely controlled without modifying the code.

[0057] Example 2 Based on the interactive content display control method provided in the above embodiments of this application, this application also provides a corresponding interactive content display control device, such as... Figure 4 As shown, Figure 4 A schematic diagram of the structure of an interactive content display control device 40 provided in an embodiment of this application. The interactive content display control device 40 includes: The configuration acquisition module 401 is used to acquire the activity configuration data sent by the server. The activity configuration data includes the activity's display sequence number, targeting parameters, type identifier, and display parameters. The scheduling and filtering module 402 is used to sort the activity configuration data according to the display sequence number to obtain a display queue, and to remove the activity configuration data in the display queue whose orientation parameters do not match the current running environment parameters of the host page to obtain a target display queue. The loading control module 403 is used to determine the target activity according to the order of the target display queue, determine the routing address corresponding to the target activity in the activity sub-application according to the type identifier of the target activity, concatenate the routing address with the display parameters of the target activity to obtain the loading address of the target activity, and write the loading address into the isolation container in the host page, so that the isolation container loads the activity sub-application page pointed to by the loading address; wherein, the activity sub-application and the host page are independently managed, built and deployed, and the isolation container is used to isolate the activity sub-application page from the host page in terms of document object model, style scope, script context and routing; The message processing module 404 is used to receive the interactive message sent by the activity sub-application through the cross-document message channel, verify the source identifier carried by the interactive message, and distribute the message according to the message type of the verified interactive message; wherein, when the message type is a closed type, the next activity in the target display queue is determined as the new target activity, and the display continues according to the new target activity until all activities in the target display queue have been displayed.

[0058] Optionally, the message processing module 404 is further configured to process interactive messages of the "Do Not Disturb" type and the "Resource Request" type. The scheduling filtering module 402 is further configured to remove activity configuration data based on the "Do Not Disturb" state and display the floating entry control after the display is complete. The loading control module 403 is further configured to reassemble the loading address of the resident activity and write it into the isolation container when the forced display flag is valid. For details, please refer to the corresponding descriptions in the foregoing method embodiments. It should be noted that the above division of modules is only an exemplary functional division. In implementing this application, the functions of each module can be implemented in the same or multiple software modules. This application embodiment does not limit this.

[0059] Example 3 This application also provides a computer storage medium storing computer-executable instructions. When executed, these computer-executable instructions implement any of the interactive content display control methods described in the foregoing embodiments of this application. These computer-executable instructions can be read and executed by an electronic device including a processor and a memory; the specific form of such electronic device is not limited in this application.

[0060] This application has now described specific embodiments of the subject matter. In some cases, the actions described in the claims can be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing can be advantageous.

[0061] The apparatus, module, or unit described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a tablet computer, a wearable device, or any combination of these devices. For ease of description, the above apparatus is described by dividing it into various units according to function. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0062] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0063] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for controlling the display of interactive content, characterized in that, Applied to the host page, the method includes: Obtain activity configuration data sent by the server, the activity configuration data including the activity's display sequence number, targeting parameters, type identifier, and display parameters; The activity configuration data is sorted according to the display sequence number to obtain a display queue. Activity configuration data in the display queue whose orientation parameters do not match the current running environment parameters of the host page are removed to obtain the target display queue. The target activity is determined according to the order of the target display queue. The route address corresponding to the target activity in the activity sub-application is determined according to the type identifier of the target activity. The route address is then concatenated with the display parameters of the target activity to obtain the loading address of the target activity. The activity sub-application and the host page are independently managed, built, and deployed. The loading address is written into the isolation container in the host page, and the isolation container loads the active sub-application page pointed to by the loading address. The isolation container is used to isolate the active sub-application page from the host page in terms of document object model, style scope, script context and routing. Receive the interactive message sent by the activity sub-application through the cross-document message channel, verify the source identifier carried by the interactive message, and distribute the interactive message according to the message type of the verified interactive message; Specifically, when the message type is closed, the next activity in the target display queue is determined as the new target activity, and the display continues according to the new target activity until all activities in the target display queue have been displayed.

2. The interactive content display control method according to claim 1, characterized in that, The targeting parameters include the region code, channel code, and login method identifier; The step of removing activity configuration data from the display queue whose orientation parameters do not match the current runtime environment parameters of the host page includes: The region code, channel code, and login method identifier in the activity configuration data are compared with the region code, channel code, and login method identifier currently used by the host page. If any item in the comparison results does not match, the corresponding activity configuration data will be removed from the display queue.

3. The interactive content display control method according to claim 1, characterized in that, The type identifiers include image display type, link jump type, and custom scenario type; The step of determining the routing address corresponding to the target activity in the activity sub-application based on the type identifier of the target activity, and concatenating the routing address with the display parameters of the target activity to obtain the loading address of the target activity includes: When the type is identified as image display type, the image display route in the activity sub-application is determined as the route address, and the image address of the target activity is concatenated as the display parameter into the query parameter of the route address; When the type is identified as a link jump, the link carrying route in the activity sub-application is determined as the route address, and the jump link of the target activity and the opening method parameter are concatenated as the display parameters into the query parameters of the route address, so that the activity sub-application can load the jump link in the manner indicated by the opening method parameter, such as opening in a new window, opening in the current page, or opening within the isolation container. When the type identifier is a custom scenario, the scenario route corresponding to the scenario identifier of the target activity in the activity sub-application is determined as the route address, and the scenario identifier is concatenated into the route address as the display parameter.

4. The interactive content display control method according to claim 1, characterized in that, The step of concatenating the routing address with the display parameters of the target activity to obtain the loading address of the target activity includes: Obtain the current runtime environment identifier of the host page, and determine the basic access address of the active sub-application corresponding to the runtime environment identifier; The basic access address, the route address represented in hash routing form, and the display parameters are concatenated in sequence to obtain the loading address of the target activity; The hash routing is a routing format that uses the hash symbol in the address and the characters following the hash symbol to represent the page route. When the active sub-application performs route jumps within the isolation container, it does not change the routing state of the host page.

5. The interactive content display control method according to claim 1, characterized in that, The distribution process according to the message type of the verified interaction message includes: When the message type is a resource request type, the host page calls the server interface to obtain the resource data indicated by the resource request type, and returns the resource data to the activity sub-application in the form of a callback message through the cross-document message channel, so that the activity sub-application can render according to the resource data; When the message type is a content click type, the host page performs the jump processing according to the jump parameters carried in the interaction message.

6. The interactive content display control method according to claim 1, characterized in that, The activity configuration data also includes an activity identifier; the method further includes: When the message type is Do Not Disturb, the activity identifier of the target activity and the corresponding Do Not Disturb status are written to the storage level corresponding to the Do Not Disturb type; wherein, the Do Not Disturb type includes valid for the current day, valid for seven days, valid for the current month, valid indefinitely, and valid indefinitely across devices; When the Do Not Disturb type is valid for the day, seven days, the month, or indefinitely, the activity identifier of the target activity and the corresponding Do Not Disturb status are written to the local storage of the browser where the host page is located; when the Do Not Disturb type is permanently valid across devices, the Do Not Disturb status of the target activity is written to the key-value cache of the server through the server interface, and the cache key of the key-value cache is generated by combining the activity identifier of the target activity and the user identifier of the current user; Correspondingly, after obtaining the target display queue, the do-not-disturb states that are in a valid state in the local storage and the do-not-disturb states in the key-value cache of the server are read, and the activity configuration data that has recorded the do-not-disturb state are removed from the target display queue to obtain an updated target display queue, so as to determine the target activity according to the order of the updated target display queue.

7. The interactive content display control method according to claim 6, characterized in that, The activity configuration data also includes a hover attribute; the method further includes: After all the activities in the updated target display queue have been displayed, the last activity with the floating attribute enabled is determined from the target display queue according to the display sequence number. The determined activity is identified as a permanent activity, and a floating entry control corresponding to the permanent activity is displayed on the host page. In response to the trigger operation of the floating entry control, a forced display flag is set, and when the forced display flag is valid, the do-not-disturb state recorded by the persistent activity is ignored, the routing address corresponding to the persistent activity is re-determined, the routing address is concatenated with the display parameters of the persistent activity to obtain the loading address of the persistent activity, and the loading address is written into the isolation container to reload the activity sub-application page corresponding to the persistent activity.

8. The interactive content display control method according to claim 1, characterized in that, After writing the loading address into the isolation container in the host page, the method further includes: After listening to the completion event of the isolation container loading, a configuration message is sent to the activity sub-application through the cross-document message channel. The configuration message carries the source identifier of the host page and the button configuration information of the target activity. The button configuration information includes the display text of the interactive control and the do-not-disturb type corresponding to the interactive control, so that the activity sub-application can render the interactive control according to the button configuration information.

9. A control device for displaying interactive content, characterized in that, include: The configuration acquisition module is used to acquire the activity configuration data sent by the server. The activity configuration data includes the activity's display sequence number, targeting parameters, type identifier, and display parameters. The scheduling and filtering module is used to sort the activity configuration data according to the display sequence number to obtain a display queue, and to remove the activity configuration data in the display queue whose orientation parameters do not match the current running environment parameters of the host page to obtain a target display queue. A loading control module is used to determine the target activity according to the order of the target display queue, determine the routing address corresponding to the target activity in the activity sub-application based on the type identifier of the target activity, concatenate the routing address with the display parameters of the target activity to obtain the loading address of the target activity, and write the loading address into an isolation container in the host page. The isolation container then loads the activity sub-application page pointed to by the loading address. The activity sub-application and the host page are independently managed, built, and deployed. The isolation container is used to isolate the activity sub-application page from the host page in terms of document object model, style scope, script context, and routing. The message processing module is used to receive interactive messages sent by the activity sub-application through a cross-document message channel, verify the source identifier carried by the interactive message, and distribute the message according to the message type of the verified interactive message; wherein, when the message type is a closed type, the next activity in the target display queue is determined as the new target activity, and the display continues according to the new target activity until all activities in the target display queue have been displayed.

10. A computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which, when executed, perform the interactive content display control method as described in any one of claims 1 to 8.

Images