Transaction Database Marketing and the consent record that survives the campaign

Summary

• Transaction Database Marketing is supported by a thin public identity record, not a current, inspectable product catalogue. The responsible assessment begins by separating that directory identity from similarly named historical marketing-software businesses.
• Transaction-led marketing is only governable when the system preserves event provenance, consent by purpose and channel, current suppression state, identity-match history, reproducible segment membership and campaign outcomes that can be reconciled to source transactions.
• Historical reports about RTMS and NuEdge show why the category mattered: retailers used purchase histories to form narrow groups and run campaigns at substantial scale. Those reports are useful context, but the available evidence does not prove that Transaction Database Marketing is the same business or that those products remain available.
• The commercial test is total operating cost. Storage and query charges matter, but so do migration, duplicate resolution, privacy operations, restore drills, campaign reconciliation and the local people required to keep definitions and permissions accurate.

A company name is not a capability statement

Transaction Database Marketing is one of those names that can seduce a researcher into writing the product before finding the company. Each word carries technical promise. "Transaction" suggests a reliable event. "Database" suggests persistence and retrieval. "Marketing" suggests a decision made from the record. Put together, the phrase evokes a system that knows what a customer bought, decides what might be relevant next and delivers the decision to a campaign channel.

The public identity evidence is much thinner than that imagined system. The BTW directory entry describes Transaction Database Marketing as a United States company record appearing in the ARIN member directory. It does not expose a current product site, technical manual, service description, customer list, deployment model, pricing schedule or support commitment. The page marks the company's current status as not yet assessed. ARIN itself explains that its registration-services reports concern organisations and Internet number resources covered by registration agreements. Such a record can establish a registry relationship or naming signal. It cannot establish what software a company sold, how it processed customer data, whether a service is still active or whether a named organisation operated the network on which an application once ran.

That distinction matters because public records contain nearby names. A Cook County human-rights index refers to a case involving "Transaction Database Marketing, Inc." in 1999. Separately, the Federal Trade Commission recorded a 2000 transaction in which The Great Universal Stores P.L.C. was the acquiring party and Retail Target Marketing Systems, Inc. was an acquired entity. Period trade reporting called that business RTMS and described an Archer software product. A trademark record for RTMS described software for retailers that handled and analysed customer purchase and sales data for marketing and internal record-keeping. Later reports connected RTMS to NuEdge Systems, Experian and Metavante.

These records occupy the same conceptual neighbourhood, and some share a Wisconsin setting and early database-marketing vocabulary. But resemblance is not corporate proof. The available public material does not establish that the directory entity Transaction Database Marketing is Retail Target Marketing Systems, that the Cook County respondent was the RTMS software business, or that rights and obligations flowed among those names in a particular way. A current buyer should not inherit an entire product history from a near match.

Corporate identity requires a documented chain of legal names, ownership, assets and contracts, not a confident acronym expansion.

This is more than an archival nicety. It sets the burden for every claim that follows. Transaction Database Marketing can be assessed as a directory company with a relevant name and a limited public footprint. Historical systems in the same field can show what transaction-database marketing was designed to do and what a modern buyer should demand. They cannot be presented as the company's current product, current customer base or current performance.

That leaves a useful article rather than an empty one. Thin evidence changes the task from product celebration to control analysis. What would have to be true for a transaction database to support marketing safely? Which records should survive each campaign? How could a buyer distinguish a functioning decision system from a pile of customer rows? And which costs appear only after a marketing team begins to depend on it?

The historical category was already operational, not decorative

The nearby RTMS and NuEdge record shows that database marketing was never merely a nicer address book. A Chief Marketer account of Quality Stores from 2000 said the retailer used Archer software from RTMS to combine previous purchase history with demographic information for a loyalty programme. The report described repeated mailings across test markets and segments that distinguished established buyers, lapsed buyers, demographically plausible non-buyers and sporadic purchasers. It also described a Mother's Day campaign in which purchase records were merged with profile information to select among different offers.

An InformationWeek report on Bridgestone/Firestone described NuEdge campaign-management software segmenting customer information collected from point-of-sale systems. The operating variables were familiar: visit frequency, spending and recency. The report discussed lapsed-customer campaigns and quoted company-supplied response signals. A later report on Interline Brands described Customer Miner, a NuEdge analysis and segmentation module, as part of an analytics and campaign-management suite.

These are contemporary trade reports, not controlled audits. They do not expose source data, matching rules, campaign code, consent records, holdout design, delivery logs, returned mail, unsubscribe handling or margin reconciliation. They are nevertheless valuable because they show the real operating surface. The software sat between sales systems and campaign execution. It transformed purchases into groups, and groups into different treatments. The important output was not a colourful chart. It was a decision about which identifiable person would receive which message or incentive.

The corporate trail is clearer for NuEdge than it is for Transaction Database Marketing. A 2003 trade report said Experian acquired the remaining half-share in NuEdge from an RTMS holding company and described NuEdge as a provider of customer-relationship software, consulting and production-management systems. A later SEC filing states that Metavante acquired NuEdge Systems in October 2004 for approximately $1.4 million and described the business as providing customer-relationship management solutions for enterprise marketing automation. FIS then completed its acquisition of Metavante in 2009.

That sequence says something important about software continuity. A product can move through a joint venture, a brand change, an asset purchase, a merger and a larger platform integration while its original name disappears. Acquisition proves that an asset or company changed hands at a point in time. It does not prove that every module remained supported, that every customer migrated, or that an old entitlement maps to a current service.

Anyone evaluating a legacy transaction-marketing installation needs product-level evidence: the executable version, licence owner, database engine, supported operating environment, maintenance status, source and export rights, and named team that can still resolve a defect.

The old reports also make a modern privacy point. The underlying action has not changed merely because direct mail became email, mobile messaging, advertising audiences or personalised web content. A system observes behaviour, forms an identity, assigns that identity to a segment and triggers differentiated treatment. More channels and faster models increase the possible uses of the record. They also increase the number of places where permission, suppression and lineage can go wrong.

The transaction must remain an event

The safest foundation is an event record, not a mutable customer total. A purchase occurred at a particular time, through a particular channel, under a particular account or token, for particular products and amounts. A return, cancellation, correction or chargeback occurred later. Each event may be late, duplicated, reversed or linked to the wrong identity. If a database simply overwrites "lifetime value" or "last purchase" whenever a feed arrives, the marketing view can look current while losing the history needed to explain it.

A governed transaction layer therefore keeps source facts and derived facts separate. Source facts identify the upstream system, reference, event type, event time, ingestion time, currency, location or channel, correction state and version. Derived facts include recency, frequency, monetary value, category affinity, predicted propensity and segment membership. The derived result should point back to the inputs and rule or model version that produced it. The W3C PROV-O recommendation provides a general vocabulary for entities, activities, agents, generation, use and derivation. A marketing platform need not store its operational tables in RDF to learn from the model: a result is far easier to trust when the system can say what generated it, what it used and who or what was responsible.

This separation solves several practical disputes. If a customer says a purchase was returned, the system should not erase the original purchase as though it never happened. It should record the return, update the permitted marketing view and retain an auditable relation between the events. If a point-of-sale feed arrives twice, an idempotency key or source-event identifier should prevent double counting. If a batch was delayed for three days, both event time and processing time should remain visible; otherwise a marketer may believe a segment was fresh when it was built from stale data.

The British government's Data Quality Framework is useful here because it refuses to compress quality into one score. It distinguishes completeness, uniqueness, consistency, timeliness, validity and accuracy. A complete transaction table can still be inaccurate. A valid email format can belong to the wrong person. A unique loyalty identifier can represent a household rather than an individual. A timely feed can contain duplicate refunds. A consistent set of country codes can still reflect a source whose collection purpose does not cover the proposed campaign.

Those distinctions should become measurements, not workshop language. A buyer should ask for the percentage of events received within the agreed freshness window, duplicate rate by source, unresolved correction count, proportion of customer records without a stable source identifier, volume of late-arriving transactions, reconciliation difference against the finance or order system, and the number of campaign decisions built on data later corrected. There is no universal acceptable threshold. There must be an owner, an agreed purpose and a visible trend.

The same rule applies to deletion and retention. Removing a customer profile from an activation table should not silently remove the evidence that an accounting transaction occurred where another legal basis requires it to remain. Conversely, an accounting obligation does not grant indefinite marketing use. The architecture needs purpose-specific views and retention, with the marketing surface receiving only the fields and history it is allowed to use. A single undifferentiated "customer database" invites every downstream team to treat possession as permission.

Consent is a changing record, not a checkbox

The most dangerous field in a marketing database is often a Boolean called consent. It looks decisive and usually hides the questions that decide whether it means anything. Consent to what purpose? For which channel? Given to which legal entity or brand? Under which notice? In which jurisdiction? Collected directly or through a partner? Was the person an adult? When did the permission begin, and when was it withdrawn? Did the source prove an affirmative action, or merely the absence of an objection?

A useful consent record behaves like a versioned state machine. It includes the subject identifier, purpose, channel, scope, status, collection source, notice or terms version, timestamp, jurisdiction, evidence pointer and effective period. A change appends a new state or event. It does not rewrite history. Campaign eligibility is calculated from the latest applicable state at the decision time, not from whichever Boolean happened to land in the profile table last.

The legal rules differ by jurisdiction and channel, but the engineering lesson is stable. The EU General Data Protection Regulation requires personal data to be processed lawfully, fairly and transparently, collected for specified purposes, limited to what is necessary and kept accurate where required. It also gives people a right to entity to processing for direct marketing, including related profiling. The UK's Information Commissioner's Office says in its direct-marketing guidance that an objection must stop the relevant use and that withdrawal of consent should stop the marketing it covered as soon as possible. In the United States, the Federal Trade Commission's CAN-SPAM compliance guide says commercial email recipients need a clear opt-out method and that requests must be honoured within ten business days.

These references are not a universal legal opinion, and a global operator needs counsel for the countries and channels it serves. They do establish why the database design cannot assume one worldwide permission rule. The decision service must know enough about residence, collection context, message type and channel to apply the right policy. If that context is missing, "global marketing consent" is not a safe default. It is an unresolved data-quality problem.

Consent drift occurs when systems copy permission without copying its meaning. A customer checks a box in an ecommerce checkout. A customer-data pipeline exports email_opt_in=true. A warehouse joins it to a master profile. A campaign tool imports the profile. A second brand or regional team reuses the audience. At each handoff, purpose, notice version, brand scope and withdrawal route may be dropped. The final system contains a true value with a false implication.

The control is a consent lineage test. Select a sample of campaign recipients and trace their eligibility back through every transformation to the original evidence. Then reverse the test: submit a withdrawal or objection through each supported channel and verify that it reaches every activation destination within the required time. Public evidence offers no basis to say Transaction Database Marketing passes either test. Those are the tests a buyer would need to run in an authorised environment.

A suppression list is operational memory

Suppression is often treated as the negative residue of marketing, a file of people who should not receive the next campaign. In fact, it is one of the system's most important durable records. A preference centre can change. A profile can be deleted and later recreated. A retailer can buy a new list containing an old address. Two brands can merge databases. Unless the objection survives those events, the company can contact the person again precisely because it forgot why the record disappeared.

The ICO explains this clearly: when someone no longer wants direct marketing, an organisation should usually place the minimum necessary details on a suppression or do-not-contact list rather than simply delete every trace. The list exists to prevent future use for the objected purpose. It should be checked against new marketing lists and kept current. That creates a subtle data-design requirement. The organisation must retain enough of an identifier to recognise the person while ensuring the suppression record itself is not repurposed as a marketing audience.

A robust system makes suppression authoritative and channel-aware. It records whether the instruction covers all marketing, one brand, one channel, one address or one campaign type. It identifies the source and effective time. It propagates changes to delivery vendors and downstream audience stores. It monitors acknowledgements and exceptions. Most importantly, campaign selection should fail closed when the suppression service is unavailable or stale. Sending first and reconciling later defeats the purpose.

Freshness can be measured. How long passes between an unsubscribe event and the authoritative suppression state? How long until each email, messaging, advertising and print destination confirms the update? How many campaign rows were selected against a suppression snapshot older than the policy allows? How many identities were recreated after deletion and then relinked to an existing objection? A dashboard that reports only list size conceals the failure path.

The state also needs recovery protection. If a team restores yesterday's marketing database after a fault, it must not restore yesterday's permissions as though today's withdrawals never happened. Recovery procedures should replay consent and suppression events to the target time or reconcile them from a separately protected authority before campaign service resumes. A technically successful restore can therefore be a compliance failure if the database is consistent but the preference state is old.

Identity resolution creates value and liability together

Transaction marketing becomes more useful when records from stores, websites, service centres, loyalty programmes and support channels are linked. It also becomes more dangerous. The same identity graph that recognises one customer across several touchpoints can combine two people, split one person into several profiles, attach household behaviour to an individual or recover an identity that was intentionally separated.

Commercial descriptions of identity resolution emphasise the benefit of consolidating records and reducing duplicate or incomplete profiles. The harder question is how the merge was made. Deterministic matches use strong common identifiers such as a verified account, email address or loyalty number. Probabilistic matches infer a likely connection from weaker signals. Neither label guarantees correctness. Email addresses are shared and recycled. Phone numbers change. Postal addresses contain households. Device identifiers are reset. Names are misspelled. A strong identifier can still be attached to the wrong reference through a checkout or data-entry error.

Every match should therefore carry method, confidence, source fields, rule version and time. Merges and splits should be reversible. Sensitive or regulated attributes should not be allowed to flow across an inferred link merely because the marketing model finds the connection useful. The team should maintain a review queue for ambiguous identities and measure false merge and false split rates against labelled samples. "Profiles deduplicated" is not an outcome metric unless the error cost is visible.

Duplicate resolution also interacts with suppression. If profile A has opted out and profile B is later judged to be the same person, the system needs a policy for carrying the objection across the merge. If two profiles are split after a mistaken match, it needs to preserve the reason and avoid removing a valid suppression from the real objector. These are not edge cases in a mature database. They are ordinary consequences of changing source data.

Segmentation leakage follows when a mistaken or overly broad identity exposes a person to treatment based on another person's behaviour. A shared household purchase may trigger an intimate product message. A business account may be treated as an individual's preference. A returned purchase may remain in a propensity feature. The harm is not captured by overall campaign response. A campaign can improve aggregate conversion while producing unacceptable individual decisions.

For Transaction Database Marketing, no public evidence reveals an identity model, matching method or correction process. That absence should stop specific claims, not careful reasoning. Any buyer assessing a system in this category should request identity-rule documentation, match-quality reports, manual-review procedures, split and merge logs, propagation rules for objections, and examples of how household, device and individual identities remain distinct.

A segment should be reproducible after it has been used

Marketing teams often describe a segment in natural language: recent high-value customers, lapsed buyers, likely feed purchasers, owners of a particular vehicle or people near a store. The actual audience is the result of code, data and time. If any of those change, rerunning the same label can produce a different population.

A governed campaign keeps a snapshot or reproducible membership record. It identifies the segment definition and version, query or model version, data cut-off, source table versions, exclusions, suppression snapshot, identity-graph version, execution time and output count. Each selected member carries reason codes or the key conditions that made the person eligible. The system should also record why an apparently eligible profile was excluded. Without that evidence, the team cannot answer a complaint, reproduce a financial analysis or determine whether a change came from customer behaviour or altered logic.

This is where lineage becomes operational rather than ceremonial. The W3C provenance model's distinction among entities, activities and agents maps neatly onto a campaign. Transactions and preference records are entities. Identity matching, feature calculation and audience selection are activities. Software services, teams and approved operators are agents. The sent audience is derived from upstream records through named processes. A buyer does not need philosophical perfection. It needs enough traceability to travel backwards from one message to the relevant decision.

Segmentation leakage can also mean data from one purpose, brand or region entering another segment. A warehouse may provide broad access because centralisation is convenient. The campaign layer then relies on team convention to avoid restricted fields. That is weak control. Purpose and geography should affect the authorised data product itself: which columns, rows and derived features are available, who can query them, where computation occurs and which destinations can receive the result.

Access records matter because marketing data is attractive and portable. A segment export can contain names, contact details and inferred interests in a format that leaves the governed platform. A system should log audience creation, preview, export, delivery and deletion. High-risk exports should require approval or be replaced with controlled destination activation. Service accounts should have narrow roles. Temporary analyst access should expire. Query logs should be retained and reviewed in line with the sensitivity of the data.

None of these controls proves that the segment is commercially useful. They make usefulness assessable. The old Quality Stores report is instructive because it names the logic of its groups. A modern evaluation would go further: preserve the exact cohort, compare it with a holdout, reconcile deliveries and purchases, account for returns and incentives, and state the uncertainty. The system earns trust when another analyst can repeat the calculation without reconstructing the campaign from someone's memory.

Campaign outcomes need a financial denominator

Database marketing is sold through better targeting: higher response, less wasted contact, improved retention and more relevant offers. Those claims are plausible and often measurable. They are also easy to inflate. People selected because they already buy frequently are likely to buy again even without a message. A campaign can claim revenue that would have occurred anyway. A response rate can rise because the denominator excludes undelivered messages. A conversion can be counted across multiple channels. Gross sales can ignore returns, discounts, fulfilment cost and customer-service effort.

The system should preserve the measurement design with the audience. A controlled test records treatment and holdout assignment before delivery, prevents later selection changes from contaminating the groups and follows both through an agreed outcome window. The calculation should distinguish incremental orders, incremental gross margin, incentive cost, channel cost, returns, complaints, opt-outs and long-term effects where relevant. If randomisation is impossible, the analysis should state the comparison method and its limitations rather than presenting attribution as causation.

Historical trade reports remain signals, not portable benchmarks. InformationWeek reported large customer volumes and response relationships at Bridgestone/Firestone; Chief Marketer reported the size and cost of an Interline deployment. Those figures describe named contexts more than two decades ago. They do not establish current throughput, current pricing or a normal return for Transaction Database Marketing. A procurement model that imports them into a 2026 business case would be numerically precise and evidentially weak.

The useful metric is cost per accepted decision, not simply database cost per row. An accepted decision is one produced from sufficiently fresh data, under valid permission, with a resolvable identity, after suppression, delivered to the intended channel and reconciled to an outcome. Failed and corrected decisions consume labour even when the cloud query succeeded. When those costs are included, a smaller, better-governed data set can outperform a larger customer lake.

Campaign operations should publish a compact reconciliation for each run: input population, excluded for missing permission, excluded by suppression, excluded by data-quality rule, unresolved identities, selected treatment, selected holdout, delivered, bounced or returned, converted, reversed and finally accepted for financial reporting. Differences should have reason codes. This is the marketing equivalent of a control total. Without it, audience counts change as they pass through tools and nobody can say where the records went.

Locality is about every copy, not the primary region

Data sovereignty is sometimes reduced to a cloud-region setting. Choosing a region matters, but it is only the beginning. Transaction and marketing data can appear in ingestion buffers, replicas, backups, disaster-recovery sites, logs, support bundles, analytics notebooks, exported audiences, delivery vendors and employee devices. A system can advertise regional storage while support staff or subprocessors access data elsewhere.

A serious locality inventory follows the data by purpose and state. It records where source events are collected, where identity resolution runs, where profiles and suppression lists are stored, where backups and keys reside, which vendors receive audiences, where support can access records and how deletion or correction propagates. It distinguishes persistent storage from transient processing and identifies cross-border transfers. Contract terms, technical configuration and observed logs should agree.

The GDPR's rules on purpose, minimisation and international transfers make this especially important for European personal data, but locality is not only a European concern. Countries impose sector, consumer, government and breach-response obligations that vary. Customers may have contractual localisation requirements even where legislation allows transfer. Latency, resilience and support coverage also shape architecture. A global category label does not remove the need for a country-by-country operating map.

Locality affects incident handling. If a suppression failure occurs in one region, can local staff stop campaigns without waiting for another time zone? If a regulator asks for evidence, can the team identify the relevant copies and processors? If a customer asks for access or correction, does the workflow reach every destination? These questions connect the assigned topics of data locality and local support labour. A regional data store without people authorised and trained to operate it is a location, not a capability.

Migration is the other side of sovereignty. A buyer should know whether transaction events, consent history, identity edges, segment definitions, suppression records, delivery logs and model metadata can be exported in documented, usable formats. Exporting current profiles alone is not enough. It leaves behind the history required to explain permissions and decisions. The right to move data has little value if definitions, rule versions and relationship history remain proprietary.

Recoverability must include the decision state

Database recoverability is often tested at the storage layer: can the engine restore tables after corruption or deletion? PostgreSQL's documentation on continuous archiving and point-in-time recovery explains how a base backup and write-ahead-log archive can recreate a consistent database state at a chosen time. That is an important mechanism, but a marketing system spans more than one database. It may include event ingestion, identity services, a consent authority, a warehouse, audience files and external delivery platforms.

The recovery plan must define a consistent business point. Suppose a transaction feed was processed, an identity merge completed, a customer opted out, a segment was selected and a delivery file was sent. Restoring only the warehouse to an earlier time can orphan the consent change or cause the same audience to be sent twice. Replaying every event can also retrigger side effects unless external actions have idempotency controls.

An adequate test starts with recovery objectives for each component and the dependencies among them. It restores into an isolated environment, replays events, reconciles counts, validates permissions and suppression, checks identity versions, confirms that sent campaigns are marked as sent, and proves that exports cannot be repeated accidentally. It measures actual recovery time and data loss against the promise. A backup success notification is not a restore test.

Partial failure deserves its own rehearsal. What happens when transaction ingestion succeeds but feature calculation fails? When suppression propagation reaches email but not an advertising destination? When a merge is committed in the identity service but not in the profile table? When a query times out after writing half an audience? Systems should use checkpoints, idempotency keys, durable queues and compensating actions appropriate to the workflow. Operators need a visible exception queue rather than a silent retry loop.

Public sources do not show whether Transaction Database Marketing operated any of these controls. They also do not provide a live endpoint on which an outsider could safely test them. The correct conclusion is not that recovery is poor. It is that recoverability remains unproven and would require authorised product and deployment evidence.

The commercial comparison must include the people

Cloud economics makes database cost look granular. Google Cloud's BigQuery cost guidance separates compute used for queries from storage, and explains choices such as on-demand versus capacity pricing, table expiration and archival. Similar distinctions exist across data platforms. They help a buyer model scan volume, reserved capacity, retention, backups, replication and export.

Those charges are only the visible layer. Transaction marketing creates data-quality labour: reconciling feeds, investigating duplicates, reviewing identity matches, maintaining consent mappings, monitoring suppression propagation, approving segments, explaining anomalies, handling customer requests, testing recovery and proving outcomes. It creates migration labour when schemas, identifiers and campaign histories must move. It creates support dependency when only a vendor or a few long-serving staff understand an old rule.

Historical pricing signals underline the point without supplying a current price. Chief Marketer reported that NuEdge systems commonly cost between $200,000 and $1 million in one 2002 account, depending on database size and modules, and described an Interline suite valued by industry sources at about $500,000. Those are period reports about a different, only potentially adjacent business. They should not appear in a quotation request for Transaction Database Marketing. They do show that enterprise campaign tooling was bought as an operational system with implementation and service around it, not as a trivial database licence.

A modern total-cost model should separate initial migration, recurring platform charges, per-channel activation, implementation, data stewardship, privacy operations, analyst time, local support, incident response, testing and exit. It should assign costs to accepted campaigns or decisions and include the correction burden. If one platform has lower compute cost but requires three people to reconcile every campaign, the apparent saving is not real.

Local support should be specified as an operating service. Which time zones are covered? Who can inspect source-to-campaign lineage? Who has authority to halt a send? Which languages can support customer-rights requests? What severity starts an incident? What response and restoration targets apply? Does support include data-quality investigation, or only platform availability? Can the customer access runbooks and train its own team? A named local account manager is useful, but it is not the same as engineering and privacy capability at the moment of failure.

The NIST Privacy Framework offers a useful organisational reminder: privacy risk management spans governance, data processing, communication, control and protection. Technology can automate decisions, but people still define purposes, approve rules, investigate exceptions and communicate with affected individuals. A procurement that budgets for software while assuming this work disappears will discover the labour after launch, when it is most expensive to redesign.

What a buyer should require before believing the name

The first request should be an identity and availability statement. What legal entity is offering the service? Is Transaction Database Marketing the contracting name, a historical name, a directory label or an unrelated registry record? What current product or managed service is available? Who owns its intellectual property? Which versions are supported? What changed through any acquisition? The response should include documents, not oral reassurance.

The second request should be a source-to-decision demonstration in an authorised environment. Choose one synthetic or appropriately protected transaction and follow it through ingestion, correction, identity resolution, permission evaluation, suppression, segment selection, delivery and outcome reconciliation. Inspect timestamps, versions, reason codes and access records. Then change the consent state, split a mistaken identity, reverse the transaction and recover the system to a prior point. The point is not a polished feature tour. It is whether the records remain intelligible under change.

The third request should be a quality and operations pack: freshness distribution by source, duplicate and correction rates, unresolved identity queue, false-match evaluation, suppression propagation latency, campaign reconciliation differences, failed pipeline count, restore-test results, access-review findings and incident history. Metrics should have definitions, periods and denominators. A green status without an error budget or sample size is decoration.

The fourth request should cover locality and exit. List every region, replica, backup, log store, subprocessor and support-access path. Show retention and deletion behaviour. Export a representative set of transactions, consent events, suppression records, identity links, segment definitions and campaign logs. Demonstrate that the export can be read without the vendor's application. State assistance, fees and timescales for migration.

The fifth request should cover commercial outcomes. Reproduce one campaign's population and financial reconciliation. Explain the control group, attribution window, costs, reversals and uncertainty. Separate platform performance from marketing effect. Query latency can be measured by the vendor; incremental margin depends on campaign design and customer behaviour. A responsible system keeps those layers distinct.

These requests are deliberately demanding because the system makes decisions about identifiable people from records of their behaviour. The broad phrase "database marketing" should not lower the proof burden. It should raise it. A database that cannot preserve consent and suppression is not made safe by faster segmentation. A campaign that cannot reproduce membership is not made credible by a higher response chart. A cloud deployment that cannot identify every data copy is not sovereign because its primary region was selected correctly.

The evidence burden is the product

Transaction Database Marketing remains a real directory identity with a very limited public operating picture. The adjacent historical record shows an established category of transaction-led segmentation and campaign management, and the NuEdge corporate trail shows how products and support obligations can disappear into larger acquisitions. It does not close the identity gap, establish a present offer or confer historical customers on this company.

That uncertainty is not a reason to fill the space with generic praise. It clarifies what matters. The valuable system is the one that keeps the transaction as an event, carries permission with its meaning, treats suppression as durable memory, makes identity decisions reversible, freezes campaign membership, measures outcomes against a valid denominator, maps every data copy, restores business state and gives local operators enough control to act.

The commercial winner will not necessarily be the platform with the most profiles, fastest demo or cheapest storage line. It will be the arrangement that produces accepted decisions at a lower total cost while preserving the evidence needed to defend them. Until Transaction Database Marketing can be connected to a current service and that service can show those records, the strongest conclusion is bounded: the name identifies the field, but the field's evidence burden remains unmet in public.