Buyer data, silent feeds and whether an online channel pays

Steps 7 to 9 of running an online channel: three jobs that stay with you. What the buyer’s personal data may be used for, who notices when a marketplace feed goes quiet, and whether a channel pays once its costs are counted. It follows Steps 3 to 6, the work on each order.

1. Step 7: decide what the buyer’s personal data is for, before the first order arrives.
2. Step 8: notice when a feed stops, because nothing will tell you.
3. Step 9: judge whether a channel pays, after its costs.

Step 7: Decide what the buyer’s personal data is for, before the first order arrives

Every marketplace order brings the recipient’s name, phone number and full delivery address, and BigLedger writes them onto the order. Which customer the order is billed to depends on the marketplace, and on two of them it is a choice on the marketplace branch that is easy to miss.

Shopee and Lazada (a Shopify shop reads the same setting):

• Default Entity ticked, with an entity chosen: every order from that shop is billed to that one customer, for example “Shopee buyers”. No customer record is created per buyer. The delivery details stay on each order.
• Default Entity not ticked: BigLedger looks for an existing customer with the same name and phone number, and creates one, with the address, if there is none. Over a year this builds a customer list of every marketplace buyer.

TikTok Shop: there is no choice. The TikTok order job does not read Default Entity, so ticking it on a TikTok branch changes nothing. Every order is billed to a customer record for its buyer, keyed on the buyer’s TikTok user id: the buyer’s first order creates the record, with that id as its customer code and the buyer’s name, phone and address, and each later order finds it by the id and replaces the address with the latest delivery address.

Each design has a cost. One customer per shop keeps your customer list clean and holds no personal data outside the orders, but you cannot see a repeat buyer. One per buyer lets you see repeat buyers. On Shopee and Lazada the matching is on name and phone, so a platform that masks phone numbers, or two people with the same name, will merge different buyers or split one buyer across several records. On TikTok Shop the platform’s id keeps one buyer to one record, but the record’s address is only ever the latest one. Either way, it creates a customer list of people who agreed to nothing with you: they bought on the platform’s terms, not yours. And it makes the payout reconciliation much heavier: a receipt voucher is made out to one customer, so a weekly settlement of 300 orders needs 300 vouchers instead of one (Reconciling Marketplace Payouts, Step 2). A TikTok shop always carries both costs.

• Who: the person responsible for personal data in the business decides, with the channel manager, when each shop is set up. The decision includes what the customer records may be used for. Delivery and after-sales service are what the buyer expects. Before any marketing use, check it with whoever owns personal-data compliance in the business, because the buyer never gave you consent.
• When a buyer asks to be forgotten: the customer record’s contact details can be dealt with, but the order and the invoice are tax records and stay.
• For a TikTok shop, the decision is only about use, because the records will exist. The data owner writes down what they may be used for when the shop is set up, and the channel manager tells whoever handles customer records that TikTok buyers arrive as customers on their own, with a long numeric customer code (the buyer’s TikTok id).
• How you know it is right: the decision is written down for each shop, and nobody has imported the marketplace customers into a marketing list. On a TikTok shop, open any recent order’s customer: its code is the buyer’s TikTok id, not the customer you may have chosen as Default Entity.

Step 8: Notice when a feed stops, because nothing will tell you

Marketplace orders arrive numbered and FINAL, with no queue of unworked documents. When a channel stops, BigLedger shows a quiet day. The check, and what to do when it fails, are on Best Practices §6 and in Sales That Arrive From Another System. The occupation’s half is who:

• Who: name one person per shop. Each morning they compare yesterday’s order count in the seller centre with yesterday’s sales orders on that marketplace branch.
• The alert BigLedger does send: when an order holds an item that is not linked, the Missing Order Items e-mail goes to the address list on the order job. Make sure that list names a person who is at work, not an old shared mailbox. Linking the item does not bring the order back by itself. The person named for that shop links the item the day the e-mail arrives, then widens the order job’s interval once, by hand, so the next run reaches back to the order (Best Practices §6). They know it worked when the order is on the branch with a running number.
• How you know it is right: the two counts matched yesterday, or someone has written down why they did not.

When an order is on the shop and not in BigLedger, work the chain in this order. Each question has one place that answers it:

1. Did the run happen? The order job’s row in the Scheduler, Last Run Date. It moves when a run is queued, not when a run succeeds, so a recent date is necessary and not sufficient. Then the shop’s connection record: its Remarks says whether the last credential refresh failed.
2. Did the run reach back far enough? The pull only asks for orders from the last interval. An outage longer than that leaves a gap no later run fills by itself: widen the interval once.
3. Did every item match a listing? The Missing Order Items e-mail for that shop. An order with one unlinked item is skipped whole.
4. Was the document created? The Sales Order listing on the marketplace branch, around the order date.
5. Did it finalise? Shopee, Lazada and TikTok Shop orders are numbered and finalised in the same run that creates them, so an order there with no running number, or not FINAL, is a failed run, not one waiting for a person. Re-running the order job will not repair it. Every order job skips an order that is already on the branch (TikTok Shop’s only updates its status), so a later run never numbers or finalises it. The person named for the shop reports it to support the same morning, with the marketplace order number and the branch, keeps it on their exception list, and crosses it off when the Sales Order listing shows it with a running number and FINAL.

The person named for the shop works the chain the same morning the counts disagree.

Step 9: Judge whether a channel pays, after its costs

Each shop is its own branch, so the Sales Report filtered by branch gives each channel’s sales. That is gross revenue, and it flatters a marketplace. The marketplace’s commission, fees, shipping and co-funded vouchers come off before you are paid. Your storefront carries gateway fees and its own delivery cost instead. Order prices arrive already net of the platform’s discount, with no separate discount amount. So a platform-funded voucher leaves no trace on your side at all.

A fair comparison is contribution after channel costs. You can produce it only if the fees are booked to their own accounts, per channel. That is the main reason to follow Reconciling Marketplace Payouts rather than booking the net payout as if it were the sale. BigLedger has no channel-profitability report.

• Who: finance, monthly or quarterly. The channel manager supplies the campaign and voucher context.
• How you know it is right: each channel’s contribution for the period fits on one page, with the fees by type, and the channel manager recognises the numbers.
• What to ask: did the channel add sales, or move shoppers who would have bought in a branch or on the storefront anyway? Look at whether branch and storefront sales in the same categories fell when the channel grew. A channel that loses money can still be worth keeping for reach or to clear stock. Write the reason down, so the question is asked again next year rather than forgotten.

When you are done, run the whole job’s success check.

What success looks like for this part

For each shop a written note says how buyers’ data is held and who owns the morning count, yesterday’s order count in each seller centre matches its marketplace branch, and each channel’s fees are booked to their own accounts.

Common mistakes in this part

Related documentation

• Running an Online Channel: the whole job, with its success check.
• Core Concepts: the stock calculation, the order paths and the gateway payment.
• EcomSync related applets: every job, the setup order and the troubleshooting table.
• Reconciling Marketplace Payouts: booking the fees per channel, which Step 9 depends on.