Data collection
The SDK and classroom services process the information below. The scope depends on the installed version, enabled features, host configuration and service deployment. See Versions and distribution for version differences. Include the entries used by your product in its privacy notice and third-party SDK inventory.
Swipe horizontally to see the full diagram
Business information
| Scenario | Information and example fields | Purpose | Trigger and method | Processing parties |
|---|---|---|---|---|
| Registration and profile updates | Optional business ID originId, eduUserId, nickname, avatar URL | Account mapping and member display | Submitted by your backend during registration/update; profiles are used by classroom queries and IM synchronization | Your backend, classroom service, deployed IM service |
| Classrooms and members | Classroom ID, name, schedule, member IDs, roles, roster, permissions, stage state | Access checks, classroom management, state synchronization | Creation, entry, stage changes, permission changes and ending, through HTTP and IM signaling | Classroom service, IM service and authorized clients |
| Real-time media | Microphone audio, camera video; shared screen content when sharing is enabled | Classroom communication and presentations | Collected/transmitted through the media adapter after the feature is enabled and device permission is granted; device tests can also capture locally | Host, configured media service and authorized subscribers |
| Chat | Sender ID, message ID, time, message body and attachments used | Sending, receiving and retrieving chat history | Message operations through the IM service | IM service and clients authorized to access the conversation |
| Whiteboards and courseware | Board operations, file name/format, original file or source URL, owner ID, conversion results, resource URLs | Collaboration, conversion and classroom presentation | Opening/editing a board, uploading/converting a file or reading resources | Whiteboard/conversion services, object storage and authorized clients |
| Recording, export and screenshots | Board content involved in the operation, generated files and URLs | Retaining or exporting teaching content | When the business explicitly enables and invokes the feature | Relevant recording/export services, object storage and designated recipients |
| Teaching tools | Questions, submissions, scores, groups and member IDs for enabled features | Classroom interaction and results | Submitted/queried when a supported tool is enabled in the deployed version | Classroom service and clients with role-based access |
| Server webhooks | appId, eventId, classroom/courseware IDs, names, user IDs and state; resource URLs in some events | Notify your backend of changes | HTTPS POST after an event occurs for a configured application subscription | Classroom service and your configured webhook receiver |
Names, courseware and message bodies can contain personal information entered by users. Prefer internal IDs without phone numbers or identity-document numbers for originId. Resource URLs can carry access credentials; do not publish them or log complete signed URLs.
See the Webhook event list for exact fields and omissions. Audio/video, chat bodies and original courseware files are absent from the ten documented webhook payloads. Receivers still need controls for user identifiers and resource links in those payloads.
Device and diagnostic information
Diagnostics correlate entry, connections, operations and failures. Diagnostic uploads and business webhooks use separate data paths.
| Information | Implementation and purpose | Timing |
|---|---|---|
| Application, user and classroom IDs | app_id, edu_user_id, classroom_id locate a problem; the server validates ownership against authentication context | When SDK diagnostic events are produced and uploaded |
| Random device-level ID | Web shared code, Android and iOS generate and persist a random UUID as device_id, correlating sessions within one installation/storage scope; an explicitly supplied host ID depends on host configuration | Read or generated on first resolution and reused later |
| Session and request IDs | session_id, trace_id, operation_id, signal_id correlate entry and operations | Entry, requests, operations and signals |
| Runtime environment | platform, sdk_version; optional app_version, os_version, device_model, network_type have values only when supplied by the host/platform | Attached after initialization or environment updates |
| Events and outcomes | Event name/time/stage, duration, error code/message, connection state, network-quality level and event attributes | Initialization, entry/exit, connection changes and operations; sampling, batching and retries depend on the event category |
| Source IP | The ingest service derives client_ip from request context, ignoring the same field supplied in the body | When the server receives diagnostic uploads |
These IDs can be associated with users and classrooms and are not anonymized data. The random device_id uses a UUID and does not read IMEI or MAC addresses. List host and third-party SDK collection separately.
Diagnostic attributes have an event field allowlist. The server also filters sensitive roots for nicknames, avatars, phones, email, identity numbers, passwords, tokens and message bodies. Chat content belongs to the IM business path and must not be copied into diagnostic attributes. Filters do not replace review of error messages, custom logs and uploaded attachments.
Local storage and retention
| Data | Storage method | Integration decision |
|---|---|---|
| Random device ID | Reused from host persistent storage | Clearing app data, account deletion/reinstallation and any custom ID source |
| Pending diagnostic batches | Persistent queue: IndexedDB on Web, SQLite on Android/iOS; acknowledged batches are removed | Retries, account changes, consent withdrawal and exit behavior |
| Business content and resources | Stored separately by classroom, IM, whiteboard and object-storage services | Retention, access roles, backup cycles and deletion procedures |
| Received webhooks | Receiver stores deduplication records, event data or work items | Separate retention for payloads and minimal deduplication keys |
Set retention periods separately for profiles, business content, diagnostics and webhook data. Production regions, retention periods, backups and deletion deadlines depend on the deployment and service agreement.
Dependencies and recipients
| Module | Dependency or address source | Inventory entry |
|---|---|---|
| Classroom and diagnostics | backendUrl and server-provided telemetry.ingestUrl | Actual operator, purpose, data types, region and contact |
| IM | Current Web, Android and iOS use OpenIM; addresses come from im.apiAddr / im.wsAddr | Actual self-hosted or managed-service operator, not an assumed recipient based on the component name |
| RTC | Tencent TRTC adapter | Installed SDK version and enabled features; see TRTC personal information rules |
| Whiteboards and courseware | DrawsKit/eduskit adapter, room configuration and returned resource URLs | Actual operators and purposes for whiteboard, conversion and storage services |
| Customer webhooks | Notification URL configured in the console | Your receiver plus any forwarding gateway, logging service or additional processor |
Recheck this inventory, permissions and actual network requests after dependency, provider or feature changes. See Privacy and compliance integration for implementation checks.