Hash code derived from the user’s IP address

Understand user behavior and preferences; enable personalized services (e.g., routing); improve occupancy calculations; distinguish whether requests come from the same or different users (stored in Analytics AWS account)

anonymized, no person-specific data

Provide tailor-made reports; automated alerts on significant changes in user behavior; enable continuous tracking of behavior across customers; beyond standard Matomo reports (stored in Analytics AWS account)

First name, Last name, E-mail, Language prefernce, 

user roles and permissions

Grant personalised access to the system. 

The journey planner uses personal information, such as current location, recorded journey trace and email addresses to provide it's services.

Examples, see Application Request Logs.

Data is process in order to operate the specific service.

In general, the journey planner is stateless w.r.t personal data and stores relevant data only in application request logs.

Engine Push stores user subscriptions that are managed from clients. Accounts are managed by the client, an anonymous id that acts as a shared secret binds subscriptions and preferences together.

The Push-Server of HAFAS.engine saves:

• User - represents a real user. Data: preferences for push-properties (language, thresholds, pauses, etc.; no personal data).
• Channel - represents an output channel (e.g. a device or an email-address). Data: device token, registration id, email address etc. For apps, these are cryptic strings that cannot be interpreted in any way. They are addresses that only Apple and Google can create and resolve. The app receives the address from Apple/Google and communicates it to the Push-Server. The Push-Server then uses the address to send a message via the service as a push message. For some channel types, the channel may contain personal data (email address, phone number, names).
• Subscription - represents a single subscription. Data: Information about which objects (trip, train, ...) are to be watched regarding which events (delays, platform changes, ...) at which times (days, times). No personal data is stored. It is theoretically possible to conclude a users place of home or work through complex pattern matching.
• Pushed event - a sent push message and it's content. Depending on the configured text templates, there may or may not be personal data as part of the message.

Operation of the push service.

The data is deleted after subscription expiry (e.g. x days after arrival of a trip), on user inactivity (x days without any request for a user id) or on client request. Soft-delete for x days is possible for subscriptions and pushed events.

Additionally, log files (which may contain any of the aforementioned objects) are deleted after a configurable period of time. By default this is 7 days.

User accounts with administrative functionalities exist in the backoffice UIs: API Manager, Push Backoffice, Datacockpit.

Accounts store username, password, email, roles&rights in addition to domain-specific items.

Operation of the specific service.

Accounts are deleted manually upon request. In cases where a hard-delete is not possible e.g. not to loose quota information for tenants, the account may be soft-deleted by anonymization.

Application Request Logs

Application Logs

Application logs extend the normal server logs with application-specific information: Typically the full request payload is logged in verbatim, as it is received over the network.

For several services the logged requests may contain personal data at least in:

• Feedback Emails - Email address of sender.

• Share a trip, Share a TripSearch - Email addresses of sender and receiver.

• Itinerary reconstruction for post-paid travel - Geo-positions and corresponding meta data of a recorded journey.

• Station name matching, QR code resolution, Trip Search - Current geo-position of the user.
• Push Services - User ids, emails, itineraries incl. original routing request.
• ...

Outside of Push and Backoffice HAFAS.engine itself has no user account feature, so (outside of the email addresses) this data is not usable to directly identify users.

Summaries of TripSearch requests incl. origin and destination locations and date/time, as well as technical details about the client App are forwarded to OBS Analytics, where they are processed.

Metrics store technical information about each request, this is a subset of otherwise logged information,

This includes especially:

• Foreign host: One-way hash of the client IP-address
• technical information about client, request, processing and result

Logs and metrics are used to monitor system stability, diagnose ongoing problems and post-mortem analysis.

Logs and metrics are used for quality assurance purposes (together with public transport schedule and realtime data), they are not analyzed w.r.t the behavior of individual users.

Logs are deleted, when technical logs are deleted.

Excerpts of logs may be kept longer for QA purposes.

Metrics are stored separately and the retention period is be longer.

Integrated 3rd Party Services

Engine integrates several 3rd party services that Hacon cannot control. Data required to for the respective service is forwarded. These act as independent data controllers in accordance with Art. 6 (1)(f) GDPR.

Mobility Service Providers, GIS Routers and Tariff Providers

Elements from the application request are forwarded to 3rd party providers, including origin and destination request locations and additional parameters that are used to influence price calculation.

Common examples are examples:

• General street network routing (routing request)
• Availability check for demand responsive transport or ride services (itineraries incl. routing request)
• External price computation (itineraries incl. routing request)

Notification Delivery

Push notifications are sent using an anonymized app ID. It is not possible to trace them back to individual users.

Push output channels involve several third party service providers & software: e.g. Apple Push Notification services (APNs) for push to iOS, Google's Firebase Cloud Messaging (FCM) for push to Android or SMTP-servers and email-infrastructure for sending emails.

3rd-Party Notification Source

Engine may forward itineraries to 3rd party push notification providers in order to integrate addition notification triggers.

First name, last name, (optional) short name, e-mail, (optional) phone number, user name, personalised settings (eg. language preference), password hash, assigned role(s). 

Deleted accounts are only marked for deletion for 3 months to enable potential restoration. After 3 months the account is also technically deleted.

Grant personalised access to the system. 

Last Activity: The system tracks when a user last logged in or performed an action, comments/notes, operational logs (eg. when login/logout).

(Technical) Log scope is defined on a per-project basis (deleted typically within one month).

Data visible for end users in the real-time archive is typically stored for up to 1 year, but this could also be fine-tuned in the specific environment.

System troubleshooting and security incident analysis

Name (optional), personnel ID (optional), device ID (IMEI or Android ID), phone number (optional), account used for logging into the driver app.

Associated data points that could directly or indirectly via the used device be linked to personal data: 

IP address of the device, vehicle ID, block ID, GPS track points (including speed and orientation), login and logout times, text messages exchanged with dispatchers and other drivers.

Most data is stored both on the driver's device and on the backend (eg. plan realtime data, realtime archive).

Technical logs on the backend and archive data are subject to the same retention period as mentioned above for "User's activity in Fleet". Technical logs of the driver app are usually overwritten within one week due to rotating log file names.

System troubleshooting and security incident analysis

Allow communication between control center (Fleet) and drivers and collect operational data for fleet management and monitoring.

HTTP request data, client’s IP address, target application IP address, timestamp of request

System troubleshooting and security incident analysis - only on demand, not merged with other data

App type, browser type/version, operating system, referrer URL, hostname of device, timestamp of request, IP address

Technical information storage for operation; enable troubleshooting; ensure system security

First name, last name, user name, e-mail, language preference, password hash, user roles. 

Deleted accounts don't show on the product but account references will be kept in the database for the Info messages. 

Grant personalised access to the system. 

Technical logs. They will be deleted after 14 days. 

Details of changes (eg, message creation). 

System troubleshooting and security incident analysis. 

User name, activitiy (edited by, last change, when login/logout)

Technical logs. 

System troubleshooting and security incident analysis.

IP address, App ID, Advertising ID

Location tracking, session tracking, usage analysis

Does not store any personal data.

Anonymized app ID; device token / registration ID (cryptic string from Apple/Google); possibly email/phone/name if used as channel type

Delivery of push messages via Apple/Google/SMTP; manage subscriptions; send service-related notifications

IP address, location) transmitted to Google/Apple

Display maps, stops, routes; geo pattern matching

Unique device identifier

Identify a device across services; can be used in other Productss

First two bytes of IP address; app type; visited pages; session duration; usage frequency

Improve app; tailor-made reports; automated alerts; continuous tracking of behavior (privacy-friendly)

Location, calendar, contacts (depending on user consent)

Convenience features only (no processing)

User name, (optional) First name, (optional) Second name, (optional) E-mail, (optional) Phone number. 

Activity (what was done in the system and when, possibly IP address).

Technical Logs (personal information such as drivers' names might be part of the delievered realtime informaiton eg. Siri). These logs will be deleted as per defined with the customer (from 2 days to 6 months). 

System troubleshooting and security incident analysis.

Grant access to the system.

uuid, externalId, userName, email, firstName, lastName, dateOfBirth, company, salutation, gender, address (street, houseNo, postalCode, city, state, country), billingAddress, phoneNumber, title, givenName, nameSuffix, placeOfBirth, nationality, deviceId, trip data (start station, end station, dates), entitlement metadata (validity, traveler data)

Provide, personalize, and maintain services; user identification & fraud prevention; communication & support; billing & invoicing; comply with legal/tax requirements; booking, routing, fare calculation, dispute resolution; manage accounts on mobility providers’ systems

uid, userName, email(s), firstName, lastName, deliveryAddress, billingAddress, postal code, dateOfBirth, gender, title, salutation, company, phone, mobile, fax, language, recipient, device_id, customer numbers, logpay_customer_id, paypal_payer_id, payment descriptors, account holder, issuer_id, payment details

Process and deliver orders; provide support services; ensure accurate service delivery; comply with tax, anti-fraud, and safety regulations

driversLicenseNumber, driverLicenseCountry, cardEngravedId, cardTypeId, cardPinCode, cardChipId

Provide MSP services; fulfill MSP-specific requirements; logs retained 2 weeks then deleted

Does not store any personal data. 

Collect feedback from users to improve the service

IP address of the user’s device (stored temporarily, then deleted or anonymized)

Enable delivery of content, ensure system security, analyze technical issues (security & troubleshooting)

GPS position of user

content filtering (on client only, not stored)

Email address provided by the user

Delivery of system emails (e.g., password resets, feedback forms) and trip-sharing messages