Product Operation: What should I do if DAU decreases?

This article would like to use a case of data decline to discuss the analysis ideas.

The article is mainly divided into two parts, one is some exploration of the reasons for the decline in DAU, and the other is the expansion of this issue.

1. What should I do if DAU decreases?

Before we discuss this issue, we need to clarify the definition of DAU: some companies’ DAU may be the startup UV, some companies may be the login UV, and some companies may be the UV that has performed specific behaviors.

Before discussing a data indicator, we need to first clarify the definition or specific calculation rules and statistical caliber to avoid a situation where we discuss it for a long time and finally find out that everyone has a different definition of this indicator.

For the sake of simple analysis, the definition used here is to start UV, and the analysis idea is to start from both external and internal reasons.

1. External causes

The first thing that needs to be clarified is whether the data is accurate, which may be a huge pitfall.

If the data relies on client-side reporting, problems are likely to occur when a new version is released or some functions are revised.

Common problems include missing tracking points, loss of reported data storage, interface replacement, etc.; this phenomenon is generally more obvious, and the corresponding data is basically a halving-level abnormality.

If the data is taken from certain BI reports, the addition and deletion of fields and the replacement of data tables may cause data anomalies, but these anomalies are generally obvious.

The second is to clarify whether the data is cyclical fluctuations.

Some business models have obvious cyclical effects. For example, some business models have data lows from Monday to Friday and data peaks on weekends; some business models have data peaks from Monday to Friday and data lows on weekends.

By comparing the data of several months back in the current cycle, we can basically determine whether it is a normal fluctuation or an abnormal fluctuation. In some cases, we may need to compare the data of the same period last year.

For example, some business models will be affected by the seasons. In some cities, once the rainy season arrives, travel apps such as shared bicycles will be affected, and corresponding taxi apps will also be affected.

Another thing to consider is whether there are any festivals recently. Some festivals have a positive impact on business, while some have a negative impact on business.

Finally, have operations and marketing done any activities recently? The data that appears to be declining may not really be declining. It may just be returning to normal, but the previous data was higher than normal, so it looks like a decline.

Sometimes the main cause can be defined here, and sometimes all of the above may be normal, so it is necessary to continue to break it down.

2. Internal reasons

Sometimes we are discussing the DAU of a certain function, or even the entire business is a functional module in an App. At this time, the first thing we need to look at is whether the superior entry traffic or the DAU of the entire App has changed.

We can find all the related factors through a formula or a process, and then break them down layer by layer until we find the cause.

Generally speaking, DAU = New User DAU + Old User DAU + Returning User DAU

Sometimes, returning users may not be separated out separately, which is not important, so just look at the first two items.

By splitting these factors down one or more levels, we get the following basic formula.

Next, we need to check each factor, identify the abnormal factors, and then dig deeper into the lower levels.

Assuming that the DAU of new users is abnormal, we need to go deeper to see whether it is the quantity abnormality or the retention rate abnormality.

If the quantity is abnormal, you can break it down one level according to the channel to see whether it is a single channel abnormality or multiple channels abnormality: if it is a single channel abnormality, is there a problem with the delivery of a certain channel; if it is multiple channels abnormality, is there a problem with the delivery budget being cut?

If the retention rate is abnormal, we will break it down one level according to the channels to see whether it is a single channel or multiple channels. If it is a single channel, it is suspected that a certain channel is inflating the volume, or the target groups of the channels do not match. If it is a multiple channel, it is suspected that the delivery strategy, delivery materials, or landing pages have been changed.

Assuming that the DAU of old users is abnormal, the next step is to look deeper to see whether it is the quantity abnormality or the retention rate abnormality.

If the number is abnormal, you can break it down one more layer to see whether it is Android or iOS that is abnormal, or both. Then you can split it by version to see if anything has been changed in the most recent version.

If there is an exception in retention, the same applies. Further split it according to the terminal (Android, iOS), version, and mobile phone type, and compare it with the latest version to see if there are any changes that may affect it.

Assuming that the DAU of returning users is abnormal, the next step is to look deeper to see whether it is the quantity abnormality or the retention rate abnormality.

If the number is abnormal, then check whether the number of recalled SMS messages and Push notifications sent has changed, and whether the reach rate and click rate have changed.

If the retention is abnormal, check whether there are any changes in the push strategy, the content of the push, and the incoming landing page.

After such layer-by-layer decomposition, we can generally find some anomalies. Then what we need to do is to continuously split and subdivide these anomalies. Finally, we find some points that we think may have an impact, make some guesses, and then adjust, test, and iterate.

2. Review and expansion of issues

Let's review what we did in the above problem and what we can do when we encounter this common problem.

To solve the problem of DAU decreasing, we went through the following steps:

DAU is decreasing - who is decreasing specifically - why is it decreasing - what to do.

The corresponding general problem is:

Discover the problem - convergence problem - draw a hypothesis - verify the hypothesis.

In terms of discovering problems, there is not much to say. Just look at the data every day, look for abnormal trend changes, and look for year-on-year and month-on-month changes.

The convergence problem is to continuously narrow the scope of the problem until the problem is found, usually from the outside to the inside, from the whole to the part, and then continue to subdivide and decompose.

The external cause is to first find the external system factors that may affect the current problem. Sometimes there may be no problem with the system itself, but the external environment has changed.

When troubleshooting data that shows an anomaly, you can usually first find a formula that includes all the related factors, then see which factor is abnormal, and then perform a more detailed split based on different dimensions.

For example, the DAU mentioned above = DAU of new users + DAU of old users + DAU of returning users, or the number of activations of material delivery = exposure * click-through rate * download completion rate * installation completion rate * startup rate * activation rate.

Commonly used segmentation dimensions are as follows:

• channel;
• New and old users;
• Number of key user behaviors;
• Gender, age, region;
• Version;
• Terminals, etc.

Conjectures are usually made when some data or functions do not perform well, such as the following conjectures:

• Is there something wrong with the promotion channel, method, or material? After users come, they find that it does not meet their expectations.
• Is it because the function entrance is too weak to be seen?
• Is it that the advertised content does not make users feel the value of it?
• Is the function too complicated, the path too long, and users are lost before they can feel the value?
• Is the function valuable but not in line with user expectations?
• Is there something wrong with the solution itself and it cannot meet the needs?
• Is it that the demand simply does not exist?

These are all based on past experience, or guesses based on understanding of the business and users.

After all, a conjecture is just a conjecture and needs to be verified or falsified. The next step is to give corresponding solutions based on these conjectures.

Since it is just a guess, it is best to verify it with the lowest cost, which is what we call MVP.

How to perform MVP validation?

You can verify the hypothesis based on the cost-effectiveness according to the scope of impact, the size of the impact, the possibility of impact, and the cost of implementation. It is best to perform single-factor verification, as it is difficult to attribute if there are too many factors.

Finally, continuous optimization and iteration are carried out based on these conjectures and data changes.

Briefly summarize the full text:

• Find problems: look at trends, year-on-year and month-on-month comparisons;
• Convergence problem: external + internal, overall formula + subdivision in different dimensions;
• Make assumptions based on experience and understanding of the business and users;
• Verify the hypothesis: MVP, cost-effectiveness, and single-factor authentication.

The above is the main content of this article. You are welcome to correct me, give me suggestions and criticize me.

Author: Wang Jiachen

Source: Product Manager from 0 to 1