Migrate from Netmera to Pipedrive

Netmera user records map to Pipedrive Person objects as the primary migration payload. Each user's standard profile fields (email, name, phone) map directly to Pipedrive name, email, and phone fields. Netmera device information is stored as a custom field group rather than a separate object. The migration requires a frozen Netmera segment rule capturing the full user population; we validate export coverage with a test run before committing the full extraction. Any Netmera user without an email address is flagged in the reconciliation report because Pipedrive Persons require at minimum a name or email for record creation.

Netmera custom profile attributes (string, number, boolean, date types) map to Pipedrive custom fields on the Person object. We create the equivalent Pipedrive custom field before import, matching attribute type to Pipedrive field type (Netmera string maps to Pipedrive text, number maps to numeric, boolean maps to boolean, date maps to date). Attribute values migrate as field data on each Person record. Tier and edition constraints do not apply on the Netmera side for attribute migration; Pipedrive Essential and above support custom fields without additional cost.

Netmera segments define audience rules and serve as both targeting units and export sources. We map segment membership criteria into Pipedrive as named filter views on Person and Organization lists, preserving the original segment name and audience size. Segments are documented as Pipedrive filter configurations rather than migrated objects, because Pipedrive does not have a segment-equivalent object. The customer reviews and confirms each segment-to-filter mapping during UAT before the production migration.

Netmera device records (OS, app version, push token, device model) are stored as custom fields on the migrated Person record. Push token values are preserved in a custom field for reference but are non-functional in Pipedrive, which does not send push notifications natively. We flag the push token field explicitly in the migration report and include a re-opt-in planning note so the customer's mobile team can plan token refresh separately. Device OS and app version migrate as string fields for user profile completeness.

Netmera behavioral events (page views, custom actions, trigger events) have no direct Pipedrive equivalent object. We map significant behavioral events to Pipedrive Activity records (Tasks with a custom event_type field) linked to the corresponding Person record, preserving event name, property keys, and timestamp. High-frequency events (page views, scroll events) are summarized rather than individual-record migrated because importing thousands of granular events per user produces a noisy activity timeline. The customer defines the event significance threshold during scoping.

Netmera campaign records contain name, content blocks, scheduling, and performance metrics. Campaign names and status migrate as Pipedrive Activity records with a custom campaign_name field and a custom campaign_type field (push, in-app, SMS, email) so sales teams can see campaign touchpoints in the activity timeline. Campaign content and creative assets do not migrate because they are platform-bound; widget-based creative (images up to 1MB, video up to 12MB) requires rebuild in the customer's new engagement platform or design tool. Campaign performance metrics are documented as a reference sheet for the customer's admin.

Netmera Journey orchestration flows define multi-step user-entry rules and channel sequences. Journeys do not have a Pipedrive equivalent because Pipedrive does not include journey orchestration. We document each Journey's entry conditions, step sequence, and conversion event definitions in a written Journey inventory delivered to the customer as a rebuild reference. Note that Netmera counts one conversion per user per journey, not per occurrence; this reporting discrepancy is flagged in the inventory so the customer does not misinterpret funnel performance post-migration.

Netmera tags label users and organize data for segmentation. Tags migrate as Pipedrive Labels on Person records (Pipedrive's native label feature) or as a custom multi-select field if the tag vocabulary is large. Tagless data capture is a Netmera platform feature, meaning some user records may have no tags; we document this as a data completeness note in the migration report.

Netmera survey questions and response records migrate as custom fields on the Person record, with survey questions stored as field labels and responses as field values. Survey display logic and trigger conditions are platform-configured and require rebuild in Pipedrive's form integration (LeadBooster Web Forms) or a third-party form tool. We deliver a written survey inventory documenting each survey's questions, response format, and trigger conditions.

Netmera does not expose an owner or user assignment model equivalent to Pipedrive's User object in the same way a CRM does. If Netmera user records carry an internal owner or agent assignment (via a custom profile attribute), we map that attribute value to a Pipedrive User lookup by matching on name or email. If no owner assignment exists in Netmera, Pipedrive User assignment is set during implementation based on territory or team structure, which is a post-migration administrative decision.