Feature preview

Feature Introduction

Paid content is released according to membership groups, how should the permissions be layered

The permissions of paid content are layered according to user groups: first define the membership groups and corresponding content that can be viewed, and then entrust the payment relationship to order and financial management, avoiding using hidden links or drafts as permissions. The number of groups should be controlled between three to five levels, and the fewer the rules, the less likely there will be unauthorized access and cases of content not being released.

Content Monetization Member Permissions User group

Feature Introduction

Paid content is released according to the membership group, how should the permission level be divided? Determine the group first and then determine the content: Use user groups and VIP groups to clarify 'who is who', and then set the accessible content range for each group, entrusting the payment relationship to the order and financial management. The most common mistake is to hide permissions in the link, or use draft status as 'not public' - neither of these is permission, the former is equivalent to being released once the address is shared, and the latter is easy to leak in bulk when the status is switched.

Determine the group first or determine the content?

First define the group. The basis for grouping is 'visitor identity' rather than content type: visitors, registered users, annual members, corporate customers, these four types of identity can cover the needs of most paid sites. After the group is defined, discuss the scope of content, which type of content is visible to which group, and a table can be written. Conversely, if you categorize content first, it is easy to appear that the same price tier corresponds to multiple identities, or that certain types of content are not visible to anyone.

User group Visible range Entry method Complementary capabilities
Visitor Free articles and summaries Direct access Guide to registration
Registered users Full text of basic content Email registration Leave a message and comment
Annual members Reports and columns Automatic grouping after order payment Download with attachments
Enterprise customers Custom content and API documentation Manual开通 Independent contact entry

Correspondence between grouping and permissions

The writing of rules should be as simple as possible: one content range corresponds to one or two groups, not to set permissions for each article separately. With too many exceptions at the article level, subsequent adjustments cannot be verified. When implementing, express the 'scope' as categories or tags - report content is placed in a certain category, and this category is open to groups above the annual membership. New content that falls into this category will automatically inherit the rules.

It should be reminded that 'preview' and 'release' are two different things. The draft link with the preview parameter is used to show the layout effect to the editor, it is not access control; the four states of formal documents, drafts, pending release, and recycling station manage the content lifecycle, not who can see. Mixing the two often leads to the situation where new content scheduled for a specific date is seen prematurely. After setting the access permissions by member group, you still need to confirm that the list page, search, and site map will not spit out the addresses of restricted content.

Order and member status synchronization

The other half of the paid tier is money. Order management records what was purchased and the expiration date, financial management takes over accounting and invoicing, the entry and exit of user groups should follow the order status: automatically upgrade to the corresponding VIP group after payment is completed, and automatically drop down if not renewed upon expiration. This step is bound to be missed during the peak renewal period if it relies on manual verification.

When selling through cross-border or external channels, the distribution management is responsible for the hierarchy and commission rules. It is necessary to determine the hierarchy before opening distribution: who develops who, whether the commission is calculated at one level or multi-level, and how refunds are handled; fewer rules make it easier to verify. The public WeChat account is used for message delivery, such as expiration reminders and new content notifications, and reminders are made in the system, which is more stable than having operation colleagues manually send messages.

How to self-check before going online

The most practical three checks: Access restricted content with an unregistered identity to see if only an abstract is given; Use an account of a lower tier to access a higher-tier address to confirm that it is blocked; Move an article from a restricted category to a public category, and then move it back to confirm that the rules follow the category rather than the article itself. When opening membership in bulk, first use a small number of accounts to verify the linkage between groups and orders, and then release in full.

Common questions

Can it only be hidden in the menu without tourists seeing?No. The hidden menu only affects the display of the entrance, and the address can still be accessed directly. Permissions should be set on the correlation between the scope of content and the user group.

Is it better to have more groups?Not at all. From three to five levels are enough to cover most sites. When the level is so high that it needs a document to explain the rules, it often means that the price and identity should be merged.

Can content belong to two paid levels at the same time?Yes, but it must be clear which level to prioritize. Otherwise, lower-level accounts may see content from higher-level accounts. It is recommended to categorize according to categories and not make exceptions for individual articles.

How to implement a trial?Use a temporary group with an expiration date: after activation, enter the trial group, automatically fall back after expiration, more reliable than manually deleting permissions, and also needs to record the start time of the trial on the order side.

Related functions

Preview

How to separate the content model for product cases and articles when they have different fields

The fields and processes for products, cases, and articles are different, and they should be separated into independent content models: products require parameters and specifications, cases require customers and achievements, and articles only need titles and text. After separation, the list page and detail page should take what is needed, and drafts, pending publication, and recycling stations should also follow the model, avoiding forcing three types of content into the same set of fields.

Preview

People using the in-site search convert higher, should the vocabulary be maintained separately?

People who use in-site search have a higher conversion rate, according to the e-commerce data for the day, the conversion rate of in-site search users is 4.63%, and that of non-search users is 2.77%, and about 43% of visitors go directly to the search box. The vocabulary list needs to be maintained separately: the in-site search vocabulary service handles and recalls, the SEO keyword library service attracts external traffic, and the two sets have different sources, actions, and responsible persons.

Preview

Which source is suitable for batch importing historical articles, compressed packages, and tables

When importing historical content in batches, archives with text and pictures are suitable for entering as compressed packages, and neatly formatted plain text content is suitable for entering as tables. The choice between the two entry methods depends on the proportion of resources and fields in the source. This article explains the fields that need to be checked before and after batch import, the arrangement of the status of importing drafts first and then publishing, and the method of rolling back after importing incorrectly, with the help of the recycle bin and interface query.