Your LINE target reach does not equal friends minus blocks because a third group is subtracted that nobody mentions in English. The Japanese definition, stated on the guides that document LINE Official Account Manager properly, is （友だち追加数－ブロック数－属性不明数）で導かれた友だち数. Friend additions, minus blocks, minus users whose attributes LINE could not work out. That third bucket is why your spreadsheet refuses to reconcile, and it is only the first of about six reasons. The rest are a mix of real behaviour and reporting mechanics, and telling those apart is the difference between chasing a problem and chasing a display artefact.
Table of Contents
Three counters, three different behaviours
The screen shows you numbers that look like they belong to the same system. They do not behave the same way at all.
| Metric | What it counts | Can it go down? |
|---|---|---|
| 友だち追加数, friend additions | Every account that has ever added you, cumulative from the beginning | No. Not on block, not when the user deletes their LINE account entirely |
| ブロック数, blocks | Accounts currently blocking you | Yes. It falls when somebody unblocks, and rises again if they re-block |
| 属性不明, unknown attributes | Accounts LINE could not assign inferred demographics to | Yes, as LINE accumulates enough behavioural signal to classify somebody |
| ターゲットリーチ, target reach | The residual after the three above | Yes, and for reasons that have nothing to do with what you sent |
The permanence of the first row is worth reading twice. Japanese documentation states it without qualification: 友だち追加して、その後ブロックをした場合でも、ユーザーが自身のLINEアカウントを削除した場合でも、友だち追加数は減りません. A person who blocked you three years ago is still in that total. A person who closed their LINE account and stopped existing as a user is still in that total. There is no mechanism to remove them.
So the arithmetic looks simple. Take the friend count, subtract the blocks, and you have the people you can reach. That is how every English guide describes it, it matches the two big numbers the console puts in front of you, and it would be correct if those were the only two buckets. There is a third, and it moves.
The attributes behind target reach are guesses, and LINE says so
The users in 属性不明 are not inactive or lapsed. They are people LINE has not gathered enough behavioural evidence about to guess their age band, gender or region. LINE calls the resulting demographics みなし属性, meaning deemed or presumed attributes, and its own manual carries an explicit accuracy warning: 年齢や性別など、属性で指定できるユーザー情報はLINEの利用動向から推定したみなし属性に基づいています。そのため、実際の属性と異なる場合があります.
Age and gender in your LINE segments are inferred from usage patterns and may differ from reality. That is LINE’s statement, not an agency’s caveat. Every segment count you build on top of it, and therefore target reach itself, is an estimate produced by a classifier. Treat it with the confidence you would give any other model output.
Why the ratio moves when you did nothing
Because the components have different rules, target reach and block rate both drift for reasons unconnected to your sending.
- Somebody unblocks you. The block count falls, target reach rises, and you did not send anything to cause it.
- LINE classifies a previously unknown user. They move out of 属性不明 and into target reach. Your reachable population grows without a single new friend.
- A long-dormant user starts using LINE more. Same effect, same absence of any action on your side.
- A user adds, blocks, then adds again. In the friend acquisition route report they are counted twice: 1人のユーザーが友だち追加をし、ブロック、その後また友だち追加(ブロック解除)をした場合は、2回カウントされます. One human, two additions, and your route totals will exceed your unique people.
None of that is a bug. It is what happens when a cumulative counter, a reversible counter and a classifier output are displayed side by side as though they were the same kind of thing.
Thailand publishes a different definition of the same number
If you run accounts in more than one market and compare notes with a local agency, you are working from two published definitions of one metric.
| Market | Published definition of target reach | What it excludes |
|---|---|---|
| Japan | 友だち追加数 − ブロック数 − 属性不明数 | Blocked users and users with no inferred attributes |
| Thailand | จำนวนเพื่อนทั้งหมดในบัญชีที่ไม่กดบล็อก และเป็นบัญชีที่มีการใช้งานจริงอยู่ในระบบ | Blocked users and accounts not actively in use on the system |
Thai agency documentation frames the exclusion as inactivity rather than as missing demographic data. In practice these are close to the same population, since LINE cannot infer attributes for somebody who barely opens the app, but the two framings will give you two different answers if you try to explain the gap to a finance team. When the definitions disagree, use the Japanese one. It is the one that matches how the metric is computed.
The reconciliation problems that are display lag, not reality
A large share of the discrepancies operators chase are the reporting layer rather than the audience.
| Mechanic | Documented rule | What it does to your reconciliation |
|---|---|---|
| Attribute data lag | 表示されている情報は概ね3日前の数値です | The attribute figures on screen are roughly three days old, so today’s target reach cannot be tied to yesterday’s send |
| Attribute display floor | Around 20 target reach is needed before attribute information displays | Below that the screen shows a sample rather than your data, which is easy to mistake for a real breakdown |
| Route analysis floor | 日ごとに20以上の友だち追加がない場合数値は表示されません | Days with fewer than 20 additions show nothing, so small campaigns disappear from acquisition reporting |
| History window | 最大397日間が選択可能です | Friend analytics reach back 397 days at most. Older cohorts cannot be pulled at all |
| Ad results retention | 友だち追加広告の実績値は過去5年分のみ参照できます | Friend-add ad performance is available for five years, a different window from the analytics above it |
Note the two separate thresholds of 20. One is a minimum target reach before attribute breakdowns render. The other is a minimum of 20 additions per day before route figures render. They are unrelated rules that happen to share a number, and conflating them will send you looking for the wrong fix.
Where the gap costs you money
Billing counts sends multiplied by recipients, so the recipient number is the one your invoice is built on. When you set a broadcast to all friends, the estimate the send screen shows you reflects target reach rather than the raw friend count, which is why the number on the compose screen is lower than the number on your friends dashboard.
LINE’s own broadcast manual then attaches a warning to that estimate: ※実際の配信数と差が生じる場合があります. The actual delivered count may differ from the estimate. That single line is the most important sentence in this article for anybody planning spend, because it means the figure you budget against and the figure you are billed on are two different numbers by LINE’s own admission.
Japanese sources also disagree with each other about whether unknown-attribute users receive a plain all-friends broadcast. Several state that the all-friends option is limited to target reach and therefore skips them. Others imply the opposite. I could not find a definitive statement in LINE’s own manual either way, so do not take a position on it from an article. Settle it on your own account instead, with one send.
How to reconcile the dashboard against a spreadsheet
- Record target reach and total friend additions on the same day, and note that the attribute-derived figures are about three days behind.
- Send one unfiltered broadcast to all friends.
- Read the delivered count on the broadcast results screen and compare it against the target reach you recorded. If delivered exceeds target reach, unknown-attribute users are receiving your broadcasts on your account. If it matches, they are not.
- Repeat that check after any month with heavy acquisition, because the size of the unknown-attribute bucket moves with how many new friends you have added.
- Never reconcile friend additions against unique people. The route report double counts anybody who left and came back, and the total never falls even for deleted accounts.
The two thresholds that will stop a send
The last thing that breaks reconciliation is a send that never went out. LINE’s manual for filtered broadcasts gives two hard minimums: ターゲットリーチ数が100人以上必要です to filter by attribute at all, and 選択後の推計対象ユーザーが50人以上必要です for the estimated audience after filtering. Below 100 target reach the attribute filters are unavailable. Above 100 but under 50 estimated recipients after the filter, the send is refused.
Thai agency documentation quotes 100 as the post-filter minimum rather than 50, which conflicts with LINE’s Japanese manual. Use the manual’s numbers. They are the ones the console enforces.
