What changed from V2

Version 3 of the Kevel Data Shipping models keeps the same set of log types as V2: no models were added or removed. The changes are focused on how data is transferred, plus a small number of column additions, type corrections, and name normalizations.

1. New: incremental, de-duplicated transfers

The most significant change in V3 is how data is synced to your destination.

Every model now includes a dedicated IsLastModified column, holding the timestamp at which the underlying log file was last modified in object storage.
Transfers now select data by filtering on IsLastModified, so only files that have changed since your last successful sync are re-read. This makes transfers incremental and removes duplicate rows that could previously appear when a partition was re-scanned.

2. New column (all models)

Column	Type	Description
`IsLastModified`	timestamp	Last-modified timestamp of the source log file. Drives the incremental, de-duplicated transfer behaviour described above.

3. Removed columns

The following V2 columns are not present in the V3 models:

Model	Removed columns
Click	`RelevancyScore`
Conversion	`RelevancyScore`, `Fraudulent`
Custom Event	`RelevancyScore`, `Fraudulent`
Selection	`Revenue`
Request	`UserGroup`, `IsHoldout`, `HoldoutGroups`, `HoldoutAdId`, `HoldoutCampaignId`, `HoldoutAdHoldoutGroups`, `TargetedSearchTerms`, `MatchedSearchTerm`

Several of these fields remain available on other models. For example, RelevancyScore on Impression and Selection, and the holdout/search-term fields on the event models. On Request, the user's group is available as RequestUserGroup.

4. Column type changes

Column	V2 type	V3 type	Affected models
`DecisionIdx`	integer	bigint	Conversion, Selection
`Keywords`	string	json	Request
`LocationLatitude`, `LocationLongitude`	float	double	Impression, Click, Conversion, Custom Event, Selection
`EventMetadata`	string	json	Custom Event
`Count`, `DecisionCount`	integer	bigint	Decision
`RtbAdIds`, `BidRequestAdIds`, `MatchedBidRequestAdIds`	string	json	Decision
`ContentKeys`	string	json	Decision

5. Column name normalizations

Column names were normalized to consistent PascalCase in V3.

V2 name	V3 name	Affected models
`Burnin`	`BurnIn`	Click
`Dt`	`dt`	Click
`RelevanceScore`	`RelevancyScore`	Click, Custom Event
`TimezoneId`	`TimeZoneId`	Impression, Click, Custom Event
`DataCenter`	`Datacenter`	Custom Event
`LocationSubRegion`	`LocationSubregion`	Custom Event
`user_key`	`UserKey`	UserDB
`action`, `interest`, `custom`	`Action`, `Interest`, `Custom`	UserDB
`RtBAdIds`	`RtbAdIds`	Decision
`FloorCPC`	`FloorCpc`	Decision

In addition, the Request model's column names, which used irregular casing in V2, are all normalized in V3:

V2 name	V3 name
`DeviceBrandname`	`DeviceBrandName`
`DeviceBrowsermajorversion`	`DeviceBrowserMajorVersion`
`DeviceBrowserminorversion`	`DeviceBrowserMinorVersion`
`DeviceBrowserrawversion`	`DeviceBrowserRawVersion`
`DeviceFormfactor`	`DeviceFormFactor`
`DeviceModelname`	`DeviceModelName`
`DeviceOsmajorversion`	`DeviceOsMajorVersion`
`DeviceOsminorversion`	`DeviceOsMinorVersion`
`DeviceOsrawversion`	`DeviceOsRawVersion`
`Enablebotfiltering`	`EnableBotFiltering`
`Enableuserdbip`	`EnableUserDbIp`
`Gdprcomputed`	`GdprComputed`
`Gdpriseu`	`GdprIsEu`
`Gdprraw`	`GdprRaw`
`Gdprsource`	`GdprSource`
`Hostname`	`HostName`
`Isvalidua`	`IsValidUa`
`LocationCountrycode`	`LocationCountryCode`
`LocationCountryname`	`LocationCountryName`
`LocationDmacode`	`LocationDmaCode`
`LocationMetrocode`	`LocationMetroCode`
`LocationPostalcode`	`LocationPostalCode`
`Networkid`	`NetworkId`
`Referrerurl`	`ReferrerUrl`