Definition
Card attribution is the project, customer, agent, or distributor an IoT SIM belongs to. The SIM is bound to that attribution when it is activated, and the binding is used for organization, access control, sales attribution, and revenue share. Attribution runs through the card lifecycle and is the base of multi-tenant permissions on the IoT Cloud Platform.
Attribution dimensions
- Project: The SIM belongs to a specific project, so it can be managed, totaled, and included in operator reconciliation at project level, including project cost and reports.
- Customer: The SIM belongs to a B2B customer, so service, bills, e-invoices, and accounting can follow that customer.
- Channel: The SIM belongs to an agent or distributor, which supports sales attribution and settlement and revenue sharing, so the share lands on the right channel.
- User: In a consumer scenario, after the user binds the SIM, it belongs to the user account, for user self-service, plan subscription, and usage lookup.
When attribution is bound
Attribution is usually fixed at two moments. At resource allocation, the enterprise assigns SIMs to a channel or a project, and the channel or project attribution is bound then. At card activation, an agent’s purchase is attributed to that agent, and a consumer activation is attributed to the user account. Resource allocation and card activation are the two binding points. The platform has to keep attribution accurate and traceable.
Where it is used
Card attribution is a core dimension of card information query, resource allocation, data billing, and operator reconciliation. A role can be limited to SIMs of one attribution, which is what multi-tenant, multi-department, and multi-project work needs. The platform can filter, export, and total by attribution, for channel review, project cost analysis, and settlement statements.
Changing attribution
Attribution is usually fixed at activation and is not changed at will, so sales attribution and settlement and revenue sharing stay traceable. In special cases, such as a project merge or a channel adjustment, the platform can change attribution, and it must keep a change log for audit. After a consumer binds the SIM, it belongs to the user account. After unbinding, attribution can return to the enterprise or the channel.
Permissions and data isolation
Attribution can isolate data and permissions. An agent can see and operate only SIMs attributed to that agent. A project admin can manage only SIMs attributed to that project. Roles can be granted by attribution, for multi-tenant and multi-project work. Attribution is also a filter on settlement statements and operator reconciliation reports, so accounting can split by channel and by project.
When a SIM carries both a project id and a channel id, which one governs
Card attribution is not a customer name in a single dropdown. It is a set of relationships that can exist together: project, enterprise customer, agent or distributor, and end user. Query permission, bill totals, and revenue share can each use a different column. The conflict appears when “primary attribution” was never defined. A SIM can sit on an East China project and also under an agent. If suspend approval follows the project and revenue share follows the agent, both sides can explain themselves until settlement does not match. Each SIM should say which column is primary. The other columns are labels. A change of primary attribution writes an effective time. Historical bills still use the primary attribution from before the change. The last three months of traffic cannot be moved onto the new project. A user binding only adds the user column. It does not overwrite the channel column. When SimtoLink reports by attribution, project cost and channel sales on the data dashboard must be able to choose different attribution columns, so one chart does not add the two bases together.
Transfer, activation, and binding each write a different column
A resource transfer usually writes the channel or the project, and the SIM still cannot go online. If an agent performs the activation, the channel of the activating account should be checked against the channel already on the SIM. If they differ, refuse. Do not silently change attribution. If the enterprise activates on the agent’s behalf, the channel stays as it is, and only the status moves from unactivated to usable. A user binding writes the user column, and that column can filter consumer queries. Unbinding clears the user column. The SIM returns to channel or project stock, and whether it can be sold again depends on whether a plan was already opened on it. In a bulk import of attribution, an empty cell has to mean either “do not change” or “clear,” and the template has to fix which one. Using a blank cell to clear the channel is a common way a sold SIM becomes ownerless. The import result should list the failed rows: the SIM does not exist, the SIM is already retired, or the operator is not allowed to change this column. Those three failures cannot be collapsed into one line that says “import failed.”
After attribution changes, do old orders stay with the original channel
Attribution can change. An order that is already closed cannot follow it. Renewal share looks at the channel snapshot on the SIM when the order was created, not at the channel on the day of the query. If “correct historical attribution” is allowed, it can only be a reversal: a negative adjustment order, not an edit of the channel id on the original order. When projects merge, moving SIMs to the new project should keep a migration batch id. Operator reconciliation may still bill by the old project’s purchase batch, so cost collection has to map the old batch onto the new project. Between tenants, changing attribution must not move a SIM from enterprise A to enterprise B. That is an inter-tenant transfer, and it requires cancellation and then a new stock-in. On permissions, an agent can see only SIMs whose primary attribution or channel column equals themselves. Being able to see them is not the same as being able to change them. An audit records at least the old value, the new value, the operator, and whether the source was a page, an API, or an import file. The import file itself should be kept. A single line that says “bulk change” cannot reconstruct which SIMs were changed when there is a dispute.