How to Slash Mobile App Log Reporting Traffic: Practical Optimization Techniques

Yesterday we discussed DNS speed optimization for the app era; today we explore log reporting traffic optimization in the wireless era.

Background: In the wireless era, app traffic is sensitive. To collect user behavior or product data, apps often report logs, which can consume a lot of traffic. This article examines methods to save traffic.

1. Can an app avoid log reporting and rely solely on server logs?

Answer: No. Some user actions (e.g., tab clicks) do not interact with the server, so server logs cannot capture all statistics.

2. Common methods for app log reporting

Answer: Three typical approaches:

Using third‑party tools like Google Analytics – no development effort but limited customization.

Designing a private protocol (e.g., binary TCP) – saves traffic but higher development cost.

HTTP reporting, often via GET parameters – the most widely used solution.

3. Details of app log reporting protocols

Typically an empty file is placed on the web server; the app sends an HTTP request to that file, passing data via GET parameters. Two common formats are:

Format 1 – Fixed‑pattern

Example: http://daojia.com/up?[bj][20151021][1939][1][login]. The server and app agree on placeholders: city, date, time, user id, action. This method has poor extensibility because missing values still require placeholders.

Format 2 – Key‑Value (KV)

Example:

http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login

. It is more extensible but adds redundant key strings, increasing payload size. The author recommends the KV method.

4. Main sources of traffic waste in app log reporting

Invalid data within HTTP requests.

Redundant URLs.

Redundant keys.

High reporting frequency (every user action triggers a request).

5. Optimization techniques

Manually construct HTTP requests, stripping everything except the essential GET line and parameters.

Use short domain names (e.g., s.daojia.cn/a) to reduce URL length.

Use short keys (e.g., c=bj instead of city=bj) and standardize them.

Batch non‑real‑time reporting: store events locally (e.g., SQLite) and upload periodically or when a count threshold is reached, reducing the number of requests.

Example of batch reporting: instead of three separate requests for three clicks, send one request with count=3:

http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login&count=3

6. Ensuring data timeliness with non‑real‑time reporting

Data freshness can be maintained by uploading at specific moments such as app launch or exit, at fixed time intervals (e.g., every 10 minutes), or when a certain amount of data is collected (e.g., every 10 records). Usually these strategies are combined.

7. Additional optimization: data compression

Compressing the payload is another common way to reduce traffic.