The API's ConvertToHousehold operation converts an existing individual record to a household record, with a new individual record affiliate. This has several detrimental impacts on data hygiene, starting with the simple fact that people are not houses. The conversion means that historical transactions now appear to have been made by a house, with no insight into who within the household initiated the transaction. And because logins are moved from an individual record to the household, this problem will grow with new transactions. Moving interests from an individual record to the household means we no longer know who in the household is interested in what. This makes segmenting constituents for email communications far more difficult and error prone than it should be, because we need to look both at individual and household records. I know the individuals in my household all have very different interests and email preferences.
To remedy this, when creating a household from an individual record, instead of converting the individual record to a household record, create a new household record with the existing individual record as the primary affiliate. Memberships can still percolate up to the household level, but interests, attributes, logins, associations, affiliations, historical transactions, etc., should stay on the individual record.
In the event this is being done to the currently logged in user’s record, their session should remain active and tied to their individual record, so their individual record is still listed as the initiator of any online transactions, though the household can be the owner of the transaction.