version: 2 models: - name: int_core__duplicate_bookings description: | A list of bookings which are considered duplicates of other bookings. We currently consider two bookings to be duplicate if they have the same: - Guest user id - Accomodation id - Check-in date Bear in mind these bookings do have different booking ids. Out of a duplicated tuple of 2 or more bookings: - Our logic will consider the oldest one to be the "original", not duplicate one. - This table will contain only the duplicates, and not the original. columns: - name: id_booking data_type: bigint description: The unique, Superhog generated id for this booking. - name: is_duplicate_booking data_type: boolean description: | True if the booking is duplicate. If you are thinking that this is redundant, you are right. All records in this table will be true. But we keep this field to make your life easier when joining with other tables. - name: is_duplicating_booking_with_id data_type: bigint description: | Indicates what's the original booking being duplicated. If there is a tuple of duplicate bookings {A, B, C}, where A is the original and the others are the duplicates: - B and C will appear in this table, A will not. - The value of this field for both B and C will be A's id. - name: int_core__booking_charge_events description: | Booking charge events is a fancy word for saying: a booking happened, the related host had a booking fee set up at the right time, hence we need to charge him. The table contains one record per booking and shows the associated booking fee, as well as the point in time in which the charge event was considered. Be wary of the booking fees: they don't have an associated currency. Crazy, I know, but we currently don't store that information in the backend. As for the charge dates: the exact point in time at which we consider that we should be charging a fee depends on billing details of the host customer. For some bookings, this will be the check-in. For others, its when the guest begins the verification process. Not all bookings appear here since we don't charge a fee for all bookings. columns: - name: id_booking data_type: bigint description: The unique, Superhog generated id for this booking. - name: id_price_plan data_type: bigint description: The id of the price plan that relates to this booking. - name: booking_fee_local data_type: numeric description: The fee to apply to the booking, in host currency. - name: booking_fee_charge_at_utc data_type: timestamp without time zone description: | The point in time in which the booking should be invoiced. This could be the check-in date of the booking or the date in which the guest verification started, depending on the billing settings of the host. - name: booking_fee_charge_date_utc data_type: date description: | The date in which the booking should be invoiced. This could be the check-in date of the booking or the date in which the guest verification started, depending on the billing settings of the host. - name: int_core__check_in_cover_prices description: | This table shows the active price and cover for the Check-In Hero product. The prices are obtained through a gross `GROUP BY` thrown at the payment validation sets table. It works this way because the price settings of this product were done with a terrible backend data model design. How could the prices be changed remains a mystery, and the current design does not support any kind of history tracking. When the time comes to adjust prices, we will have a lot of careful work to do to make sure that we keep history and that no downstream dependencies of this model blow up. columns: - name: local_currency_iso_4217 data_type: character varying description: A currency code. - name: checkin_cover_guest_fee_local_curr data_type: numeric description: | The fee that the guest user must pay if he wants to purchase the cover. - name: checkin_cover_cover_amount_local_curr data_type: numeric description: | The amount for which the guest user is covered if he faces problems during check-in. - name: int_core__unified_user columns: - name: id_user data_type: character varying description: The unique ID for the user. tests: - not_null - unique - name: int_core__vr_check_in_cover columns: - name: id_verification_request data_type: character varying description: The unique ID for the verification request. tests: - not_null - unique - name: int_core__mtd_booking_metrics columns: - name: date data_type: date description: The date for the month-to-date booking-related metrics. tests: - not_null - unique - name: int_core__mtd_aggregated_metrics description: | The `int_core__mtd_aggregated_metrics` model aggregates multiple metrics on a year, month, and day basis. The primary sources of data are the `int_core__mtd_XXXXX_metrics` models, which contain the raw metrics data per source. This model uses Jinja templating to dynamically generate SQL code, combining various metrics into a single table. This approach reduces repetition and enhances maintainability. tests: - dbt_utils.unique_combination_of_columns: combination_of_columns: - date - metric columns: - name: year data_type: int description: year number of the given date. tests: - not_null - name: month data_type: int description: month number of the given date. tests: - not_null - name: day data_type: int description: day monthly number of the given date. tests: - not_null - name: is_end_of_month data_type: boolean description: is end of month, 1 for yes, 0 for no. tests: - not_null - name: is_current_month data_type: boolean description: | checks if the date is within the current executed month, 1 for yes, 0 for no. tests: - not_null - name: date data_type: date description: | main date for the computation, that is used for filters. It comes from int_dates_mtd logic. tests: - not_null - name: metric data_type: text description: name of the business metric. tests: - not_null