Computer-implemented methods of updating links in a website; systems and computer program products

Abstract

There is disclosed a computer-implemented method of updating links in a website backend with updated links, wherein the updated links in the website backend are made available to a website frontend in

Description

[0001] COMPUTER-IMPLEMENTED METHODS OF UPDATING LINKS IN A

[0002] WEBSITE; SYSTEMS AND COMPUTER PROGRAM PRODUCTS

[0003] BACKGROUND OF THE INVENTION

[0004] 1. Field of the Invention

[0005] The field of the invention relates to computer-implemented methods of updating links in a website, and to related systems, link updaters, computer program products and computers.

[0006] 2. Technical Background

[0007] Managing the (e.g. internal) linking efficiently in a web site is an unsolved problem. For example, a website may have internal linking data deriving from former static inhouse sources, from a dynamic in-house data generation pipeline and from external parties (e.g. agencies). Even though these links are all displayed on the frontend of the website server system, there is no unified method for ingesting, storing or delivering these links from the backend of the website server system. There is a need for a core infrastructure that can handle internal links generated dynamically inhouse and optionally those links provided by external parties (e.g. agencies), and optionally to consolidate many data sources for internal linking that may currently exist.

[0008] 3. Discussion of Related Art

[0009] EP2767913A1 and EP2767913B1 disclose a system and method for virtual data warehouses having table link capabilities. In particular, some embodiments include a plurality of virtual data warehouses built on top of a data center running Apache Hive. Each virtual data warehouse can be modeled as a database and manage data in forms of database tables. The virtual data warehouse can include links which import tables from other virtual data warehouses by reference. Each link may contain partition metadata for the table partitions by dates of the source table and retention metadata to declare the needed retention time period for the partitions of the source table. The links can be dynamic and update when the corresponding source table receives new partitions or drops partitions. When a virtual data warehouse is migrated to another data center, the system can retain necessary table partitions to remain on the current data center based on the partition metadata and retention metadata of the links.

[0010] SUMMARY OF THE INVENTION

[0011] According to a first aspect of the invention, there is provided a computer- implemented method of updating links in a website backend with updated links, wherein the updated links in the website backend are made available to a website frontend in communication with the website backend, the method including the steps of

[0012] (i) storing or accessing a multi-dimensional data structure, comprising at least two dimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multi-dimensional data structure;

[0013] (ii) receiving update link data including parameters, and using the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;

[0014] (iii) putting the updated data receiving elements into a data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;

[0015] (iv) storing new database tables using the data mapping the updated data receiving elements in the data store to the database tables, and ingesting the new database tables to a database, and recording the ingested new database tables in a table of latest versions;

[0016] (v) using the table of latest versions to obtain latest database tables from the database, and updating the links in the website backend using the latest database tables from the database, and

[0017] (vi) the website backend making available the updated links in the website backend to the website front end, in which the website frontend is in communication with the website backend.

[0018] An advantage is managing updating of linking in a web site efficiently. An advantage is cheaper updating of linking in a web site. The method has the advantage of enabling more effective use of storage space, which is cheap, instead of use of longer read times and greater use of computing resources to update links individually, which are more expensive. A computer system implementing the computer-implemented method operates more efficiently as a computer system, because link updates may be performed in bulk, rather than individually.

[0019] The method may be one wherein the website is a website for travel services.

[0020] The method may be one wherein the travel services include flights, or hotel reservations, or car hire.

[0021] The method may be one wherein the parameters define which links appear on which donor website page or pages.

[0022] The method may be one wherein the backend includes page instances, in which each page instance includes metadata relating to the page, including data relating to an address, or to a group of addresses, associated with the page, in the multi-dimensional data structure, the backend using page instances and links included in database tables relating to the address, or to the group of addresses, to provide web pages to the front end.

[0023] The method may be one wherein a respective page instance item includes respective links generated by the website owner and respective links generated by a third party.

[0024] The method may be one wherein database tables are stored in the database (e.g. DynamoDB), the database tables including page instance items.

[0025] The method may be one wherein link groups are children within a respective page instance item.

[0026] The method may be one wherein respective groups of links are associated with respective webpage instances.

[0027] The method may be one wherein the received update link data includes a respective update for respective page instances. The method may be one wherein the new database tables are stored in a format in which links associated with a URL are ready to be served from the database.

[0028] The method may be one including the step of: (vii) the website frontend serving first updated links of the updated links in webpage content of a webpage, responsive to a request for the webpage.

[0029] The method may be one including updating links in principal web pages of the website, e.g. search engine optimization (SEO) landing pages.

[0030] The method may be one wherein the update link data includes links generated by the website owner and includes links generated by third parties.

[0031] The method may be one wherein ingesting the new database tables to the database is performed using a single instruction. This is an advantage over updating links individually, which requires many instructions to update many data elements.

[0032] The method may be one wherein a new Table is stored or retained for each respective Table update. An advantage is creating a new Table is cheaper than modifying on old Table, because modifying an old Table requires many instructions to update many data elements.

[0033] The method may be one wherein recent versions of old Tables (e.g. 2 or less, 3 or less, 5 or less, or 10 or less) are stored or retained, and other versions of old Tables are deleted.

[0034] The method may be one wherein only new Tables are stored for each bulk update of Tables.

[0035] The method may be one including a step of the database serving a previous version of a database table, in response to an instruction to serve the previous version of the database table. The method may be one including a step of the database serving a previous version of a set of database tables, in response to an instruction to serve the previous version of the set of database tables.

[0036] The method may be one in which previous database tables are stored in the database with a corresponding version identifier, and the method includes the step of rolling back the links at the website backend to use the links in the previous database tables that are stored in the database with the corresponding version identifier.

[0037] The method may be one wherein database tables in the database include a version identifier.

[0038] The method may be one wherein database tables in the database include a version identifier, and database tables corresponding to a particular identifier are accessible for review / analysis using the particular identifier.

[0039] The method may be one wherein database tables in the database include a version identifier, and database tables corresponding to a particular identifier are exportable for review / analysis using the particular identifier.

[0040] The method may be one wherein updating the links in the website backend using the latest database tables from the database includes updating at least one thousand links, or at least ten thousand links, or at least one hundred thousand links.

[0041] The method may be one wherein updating the links in the website backend using the latest database tables from the database includes updating at least one million links.

[0042] The method may be one wherein updating the links in the website backend using the latest database tables from the database includes updating at least two million links.

[0043] The method may be one wherein the new database tables may only be ingested to the database, when a corresponding version identifier has been created and is used to identify uniquely the new database tables.

[0044] The method may be one wherein after the new database tables are ingested to the database, the new database tables may not be changed until further new database tables are ingested to the database.

[0045] The method may be one wherein steps (i) to (iv) include:

[0046] (a) Triggering a directed acyclic graph (DAG), including a new version number;

[0047] (b) Getting the link update data;

[0048] (c) Identifying relevant tables that are being updated;

[0049] (d) Retrieving a latest version of the identified tables;

[0050] (e) Putting the link updates to the retrieved latest version of the identified tables;

[0051] (f) Writing the results of step (e) as a new version;

[0052] (g) Importing files of the new version to a database, to create a new table in the database.

[0053] The method may be one wherein in step (iv), tables are batch imported into the database, e.g using python.

[0054] The method may be one wherein each table has its own schema.

[0055] The method may be one wherein old table versions are stored in the database.

[0056] The method may be one wherein in step (v), the latest iteration of a version metadata table is propagated to a link-service API, which is part of the backend.

[0057] The method may be one wherein the link-service API makes links available to the front end.

[0058] The method may be one wherein the link-service API uses Java. The method may be one wherein the link-service API is a backend API which uses a locally stored version table to retrieve the correct table from the database.

[0059] The method may be one wherein the link-service API is a backend API which receives input from a microsite or from a component, for frontend integration.

[0060] The method may be one wherein the link-service API is a backend API which queries a configuration service to determine which version of database tables should be used.

[0061] The method may be one wherein the link-service API is a backend API, wherein a version of a link state served by the backend API is configurable. An advantage is that a rollback to a previous link state is possible.

[0062] The method may be one wherein the received update link data includes a list of which recipient pages are linked to per donor page.

[0063] The method may be one wherein in step (v), updating the links in the website backend comprise single item look-ups by URL.

[0064] The method may be one wherein the table of latest versions of step (iv) is a separate table of versions that is stored and which sets which tables should be used for a given version.

[0065] The method may be one wherein when data is ingested, the release of that data is staggered, in two stages; the first stage is a trigger to take data in the internal linking store and push it to the database; then an approval is received before the changes are released.

[0066] The method may be one wherein retrieval is performed of the previous table versions, in which the new table versions are added to, or overwrite, the previous table versions.

[0067] The method may be one wherein table versions are immutable. The method may be one wherein the multi-dimensional data structure includes a {market} / {locale} / {page_type} structure.

[0068] The method may be one wherein externally created link data is stored in a bucket, and then a DAG is triggered to transform the link data stored in the bucket into a structure suitable for ingestion into the database.

[0069] The method may be one wherein a batch job is used to transform the link data stored in the bucket into the structure suitable for ingestion into the database, eg. using python.

[0070] The method may be one wherein step (iv) includes adding a new version to the table of latest versions, wherein the new version is a copy of the previous version except for the new database tables.

[0071] The method may be one wherein a configuration service stores data identifying which version is a current version.

[0072] The method may be one wherein the configuration service records which version of the ingested database tables is currently in use.

[0073] The method may be one wherein the ingested database tables currently in use are testable using query parameters.

[0074] The method may be one wherein a version is queryable to provide the count of total links.

[0075] The method may be one wherein a version is queryable to provide the count of total links on a specified web page.

[0076] The method may be one wherein a version is queryable to provide links by donor URL. The method may be one wherein the database is stored in database instances which are multi region. An advantage is that multi region database instances allow faster request times in different geographic regions.

[0077] The method may be one wherein one region holds the primary database which is then pushed using synchronous replication to read replicas for other regions.

[0078] The method may be one wherein update link data is validated.

[0079] The method may be one wherein the update link data is validated to ensure that web pages do not link to themselves.

[0080] The method may be one wherein the update link data is validated to ensure that Links contained on a donor page all share the same top level domain (TLD) as the donor page itself.

[0081] The method may be one wherein the update link data is validated to ensure any link can only appear once on a donor page.

[0082] The method may be one wherein the update link data is validated to check the recipient page pointed to by the link is valid.

[0083] The method may be one wherein link validity is cached. An advantage is that a particular web page is not accessed too frequently, to slow down access to the website.

[0084] The method may be one wherein update link data which fails validation is notified to an originator of the update link data.

[0085] The method may be one wherein update link data includes a configurable anchor text field.

[0086] The method may be one wherein update link data includes a tab group field. The method may be one wherein update link data is such that an internal linking state for a hostname remains the same once all pages for that hostname are generated.

[0087] The method may be one wherein the database is served via a unified link-service endpoint.

[0088] The method may be one wherein the update link data is in csv files.

[0089] The method may be one wherein the datastore format includes json or includes json compatibility.

[0090] The method may be one wherein the links are internal links.

[0091] According to a second aspect of the invention, there is provided a system including a website back end, a website front end, and a link updater in communication with the website backend, the link updater including a data store, a database and a table of latest versions, the system configured to update links in the website backend with updated links, wherein the updated links in the website backend are made available to the website frontend in communication with the website backend, wherein

[0092] (i) the link updater is configured to store or to access a multi-dimensional data structure, comprising at least two dimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multi-dimensional data structure;

[0093] (ii) the link updater is configured to receive update link data including parameters, and to use the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;

[0094] (iii) the link updater is configured to put the updated data receiving elements into the data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;

[0095] (iv) the link updater is configured to store new database tables using the data mapping the updated data receiving elements in the data store to the database tables, and to ingest the new database tables to the database, and to record the ingested new database tables in the table of latest versions;

[0096] (v) the link updater is configured to use the table of latest versions to obtain latest database tables from the database, and to update the links in the website backend using the latest database tables from the database, and

[0097] (vi) the website backend is configured to make available the updated links in the website backend to the website front end.

[0098] An advantage is managing updating of linking in a web site efficiently. An advantage is cheaper updating of linking in a web site. The system has the advantage of enabling more effective use of storage space, which is cheap, instead of use of longer read times and greater use of computing resources to update links individually, which are more expensive. The computer system operates more efficiently as a computer system, because link updates may be performed in bulk, rather than individually.

[0099] The system may be configured to perform a method of any aspect of the first aspect of the invention.

[0100] According to a third aspect of the invention, there is provided a link updater of the system of any aspect of the second aspect of the invention. An advantage is managing updating of linking in a web site efficiently. An advantage is cheaper updating of linking in a web site. The link updater has the advantage of enabling more effective use of storage space, which is cheap, instead of use of longer read times and greater use of computing resources to update links individually, which are more expensive. The link updater operates more efficiently as a computer system, because link updates may be performed in bulk, rather than individually.

[0101] According to a fourth aspect of the invention, there is provided a computer- implemented method of updating links in a website backend with updated links, the method including the steps of:

[0102] (i) storing or accessing a multi-dimensional data structure, comprising at least two dimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multi-dimensional data structure;

[0103] (ii) receiving update link data including parameters, and using the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;

[0104] (iii) putting the updated data receiving elements into a data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;

[0105] (iv) storing new database tables using the data mapping the updated data receiving elements in the data store to the database tables, and ingesting the new database tables to a database, and recording the ingested new database tables in a table of latest versions;

[0106] (v) using the table of latest versions to obtain latest database tables from the database, and updating the links in the website backend using the latest database tables from the database.

[0107] An advantage is managing updating of linking in a web site efficiently. An advantage is cheaper updating of linking in a web site. The method has the advantage of enabling more effective use of storage space, which is cheap, instead of use of longer read times and greater use of computing resources to update links individually, which are more expensive. A computer system implementing the computer-implemented method operates more efficiently as a computer system, because link updates may be performed in bulk, rather than individually.

[0108] The method may further include a method of any aspect of the first aspect of the invention.

[0109] According to a fifth aspect of the invention, there is provided a computer program product executable on a processor to:

[0110] (i) store or access a multi-dimensional data structure, comprising at least two dimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multidimensional data structure; (ii) receive update link data including parameters, and use the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;

[0111] (iii) put the updated data receiving elements into a data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;

[0112] (iv) store new database tables using the data mapping the updated data receiving elements in the data store to the database tables, and ingest the new database tables to a database, and record the ingested new database tables in a table of latest versions;

[0113] (v) use the table of latest versions to obtain latest database tables from the database, and update the links in the website backend using the latest database tables from the database.

[0114] Advantages include the advantages of the fourth aspect of the invention. The computer program product may be executable on the processor to perform a method of any aspect of the fourth aspect of the invention.

[0115] According to a sixth aspect of the invention, there is provided a computer including a computer program product of any aspect of the fifth aspect of the invention, the computer further including a processor, wherein the computer program product is executable on the processor. Advantages include the advantages of the fourth aspect of the invention.

[0116] According to a seventh aspect of the invention, there is provided a link updater computer system, the link updater computer system including a processor, a data store, a database and a table of latest versions, the link updater computer system configured to:

[0117] (i) store or access a multi-dimensional data structure, comprising at least two dimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multidimensional data structure;

[0118] (ii) receive update link data including parameters, and use the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;

[0119] (iii) put the updated data receiving elements into the data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;

[0120] (iv) store new database tables using the data mapping the updated data receiving elements in the data store to the database tables, and ingest the new database tables to the database, and record the ingested new database tables in the table of latest versions;

[0121] (v) use the table of latest versions to obtain latest database tables from the database, and update links in a website backend using the latest database tables from the database.

[0122] An advantage is managing updating of linking in a web site efficiently. An advantage is cheaper updating of linking in a web site. The link updater computer system has the advantage of enabling more effective use of storage space, which is cheap, instead of use of longer read times and greater use of computing resources to update links individually, which are more expensive. The link updater computer system operates more efficiently as a computer system, because link updates may be performed in bulk, rather than individually.

[0123] The link updater computer system may be configured to perform a method of any aspect of the first aspect of the invention.

[0124] Aspects of the invention may be combined. BRIEF DESCRIPTION OF THE FIGURES

[0125] Aspects of the invention will now be described, by way of example(s), with reference to the following Figures, in which:

[0126] Figure 1 shows a schematic diagram of an example system including a website structure and a link configuration service.

[0127] Figure 2 shows a schematic example of Step One.

[0128] Figure 3 shows a schematic example of Step Two. Figure 4 shows a schematic example of Step Three.

[0129] Figure 5 shows a schematic example of Step Four.

[0130] Figure 6 shows a schematic example of Step Five.

[0131] DETAILED DESCRIPTION

[0132] In an example, there is provided a core infrastructure for ingesting, storing and delivering internal links to principal web pages of a website, e.g. to search engine optimization (SEO) landing pages. An SEO landing page is a purpose-designed webpage that aims to rank well in search results and drive conversions or leads. The core infrastructure is able to ingest, store and deliver links generated in-house and optionally links generated by third party agencies. The core infrastructure may be flexible enough to handle future requirements for links generated in-house and optionally links generated by third party agencies.

[0133] Internal linking to principal web pages, e.g. search engine optimization (SEO) landing pages, is one of the most effective methods of distributing page authority around a web site, and therefore communicating, directly or indirectly, to search engines which web pages are considered to be the most important. Managing the (e.g. internal) linking efficiently is an unsolved problem. For example, a website may have internal linking data deriving from former static in-house sources, from a dynamic in-house data generation pipeline and from external parties (e.g. agencies). Even though these links are all displayed on the frontend of the website server system, there is no unified method for ingesting, storing or delivering these links from the backend of the website server system. There is a need for a core infrastructure that can handle internal links generated dynamically inhouse and optionally those links provided by external parties (e.g. agencies), and optionally to consolidate many data sources for internal linking that may currently exist.

[0134] System including a Website Structure

[0135] In a website structure, there is provided a front end, and a back end in communication with the front end, the backend including a database table which includes the current version of the website links, the backend including a link service API which is configured to receive a new database table of website links which replaces the previous database table of website links, in which the link service API is configured to receive the new database table of website links which replaces the previous database table of website links from a link configuration service, in which the link configuration service is in communication with the link service API. There is provided a system including the website structure and the link configuration service. An example is shown in Figure 1.

[0136] In the website structure, the terms frontend (or sometimes referred to as front end or front-end) and backend (or sometimes referred to as back end or back-end) refer to the separation of concerns between the frontend, e.g. the presentation layer, and the backend, e.g. the data access layer. The terms front end and backend may be used in respect of software. The terms front end and backend may be used in respect of hardware.

[0137] Possible Technical Requirements for providing a core infrastructure for ingesting, storing and delivering internal links to principal web pages of a website

[0138] To ensure the previous link data state is stored: link data state may be versioned; the link-service database (e.g. DynamoDB) may be configurable to serve a previous version of the link data state.

[0139] To ensure pages do not link to themselves, when raw internal linking data is ingested it may be validated by the following rule: Links contained on a donor page don't contain a (circular) link to the donor page itself; the data model defines which links appear on a donor page. A donor page is a page containing one or more links.

[0140] To ensure internal links only belong to the same hostname, when raw internal linking data is ingested, it may be validated using the following rule: Links contained on a donor page all share the same top level domain (TLD) as the donor page itself. Example TLDs are skyscanner.net, skyscanner.com.

[0141] To ensure there is / are no duplicate internal links on the page, when raw internal linking data is ingested it may be validated using the following rule: any link can only appear once on a donor page (including across all tabs, sections, subpages etc).

[0142] To ensure internal links link to valid pages / URLs, when raw internal linking data is ingested, it may be validated using the following rule: check the recipient page pointed to by the link is valid (e.g. 200 code generated, not 4xx 5xx codes generated); Link validity may be cached so that popular recipient pages aren't overly requested (e.g. spammed) with validity checks.

[0143] To ensure internal links have configurable anchor text, the data model may have an anchor text field.

[0144] To ensure internal linking state for hostname remains the same once all pages for that hostname are generated, once data is stored in link-service database (e.g. DynamoDB), it may not be changed until a new version of link data is released.

[0145] To ensure internal linking state is shared across locales of a given hostname, when raw link data is generated, the links for the primary locale may be reusable for secondary locales within a market; the data model may contain denormalised parameters to allow for translations across locales.

[0146] To ensure a new state is only generated on request, new link-data may be stored in an intermediate bucket; new link-data may only be added to the linkservice (e.g. Simple Storage Service (S3), e.g. Amazon Simple Storage Service, the link database (e.g. DynamoDB)) when a new version is (e.g. manually) created.

[0147] To ensure a state may be accessible for review / analysis, the bucket containing versioned data may be accessible by analytics applications when required.

[0148] To ensure a state should support import / export, data may be exportable / downloadable for offline analysis; it may be possible to import data from different sources, with potentially more sources added in future; Raw data contains enough information to satisfy the data model.

[0149] To ensure the number, order and text of tabs are configurable (tabs are top level groups of links), the data model may contain a field for tab group; the data model may store tab order.

[0150] To ensure if link state contains links of multiple page types we are able to group links by section (a section is a subtitled group of links), the data model may contain an optional field for a section.

[0151] Possible Product Attributes

[0152] A fast and simple process for taking link data from multiple sources and showing them on the principal web pages of a website, e.g. SEO landing pages.

[0153] Supporting the release of internal links provided by external parties (e.g. agencies) to multiple markets.

[0154] Enabling a website to serve its own internal links.

[0155] Enabling a development team to experiment with internal linking.

[0156] Providing release and rollback capabilities for new Internal Linking States.

[0157] Possible Design Attributes

[0158] The core infrastructure for linking is optimised for requests: as these links are served on principal web pages of a website, e.g. SEO landing pages, where core web vitals are critical, fast performance must be provided.

[0159] The core infrastructure for linking supports bulk updates of internal linking data, for example it may be required to ingest, store and release at least one million (e.g. at least two million), internal links at once. The core infrastructure for linking supports bulk updates of internal linking data, for example it may be required to ingest, store and release at least one thousand internal links at once, or at least ten thousand internal links at once, or at least one hundred thousand internal links at once.

[0160] The core infrastructure for linking prefers automation over manual processes: Ingestion from in-house and / or external parties (e.g. agencies) is automated where possible.

[0161] The core infrastructure for linking provides managed releases to production: Stakeholders are able to review new link states before release.

[0162] The core infrastructure for linking provides a scalable storage method: it may scale significantly to handle the release of new page types and new internal links.

[0163] The core infrastructure for linking is Cost effective: Solutions using a database (e.g. DynamoDB) for links can become expensive quickly.

[0164] The core infrastructure for linking includes versioning built into the data model: an example requirement is the capacity to rollback releases to a previous state; to avoid 'emergency' rollbacks, rolling back may be a simple process.

[0165] The core infrastructure for linking supports inclusion of (e.g. SEO) text configured by an internal (e.g. SEO) team and / or external parties (e.g. agencies); Keywords are a key part of internal linking and therefore need to be managed (e.g. by SEO team / Agencies) and enabled by the website owner. Link Generation

[0166] Relevant Technical Requirements are that new link-data may be stored in an intermediate bucket; Raw data should contain enough information to satisfy the data model.

[0167] Link data ingestion and validation

[0168] Relevant Technical Requirements are that when raw internal linking data is ingested we may be able to validate it by the following rule: Links contained on a donor page don't contain a (circular) link to the donor page itself; Links contained on a donor page all share the same TLD as the donor page itself; The recipient page pointed to by the link is valid (e.g. 200 code generated, not 4xx 5xx codes generated).

[0169] Relevant Technical Requirements are that Link validity may be cached so that popular recipient pages aren't overly requested (e.g. spammed) with validity checks.

[0170] Relevant Technical Requirements are that we may be able to import data from different sources with potentially more sources added in future.

[0171] Data model

[0172] Relevant Technical Requirements are:

[0173] The data model may define which links appear on a donor page

[0174] The data model may have an anchor text field

[0175] The data model may contain denormalised parameters to allow for translations across locales

[0176] The data model may contain a field for a tab group

[0177] The data model may store a tab order

[0178] The data model may contain an optional field for a section.

[0179] Data storage and versioning

[0180] Relevant Technical Requirements are:

[0181] Link data state may be versioned The link-service database (e.g. DynamoDB) may be configurable to serve a previous version

[0182] Once data is stored in link-service database (e.g. DynamoDB) it may not be changed until a new version of link data is released

[0183] - New link-data may only be added to the link-service (e.g. S3, DynamoDB) when a new version is (e.g. manually) created

[0184] Data may be exportable / downloadable for offline analysis.

[0185] Link service API

[0186] Relevant Technical Requirements are:

[0187] A bucket containing versioned data may be accessible by analytics applications when required.

[0188] Ability is provided to maintain an 'Internal Linking State' that may enable rolling back to a previous state.

[0189] Changes to the 'Internal Linking State' may be driven by a (e.g. SEO) team. Highlighting that link text updates may be separate and may use a separate process.

[0190] Solution Examples

[0191] Regarding external suppliers of links, for Pre-Ingestion, an Automated process is provided, e.g. triggered by upload of new agency files (e.g. for SEO). Validation of urls and keywords is carried out. Failed validation for any values creates feedback to external suppliers of links (e.g. SEO agencies) with any incorrect data highlighted. Success leads to the output of the external supplier (e.g. agency) files (e.g. to s3) for uploading to data store. For Ingestion, there is provided a (e.g. manually) triggered process that reads new link data, updates the data store and maintains the previous link state. For storage, storage is provided in the database (e.g. DynamoDB), with link groups as children within a page instance item. Page instances can store link groups generated inhouse and by agencies side by side.

[0192] For delivery, the solution is served via a unified link-service endpoint. Regarding links supplied by the website operator itself, for Pre-Ingestion, an Automated process is provided, in which the files are typically much larger than in prior approaches, and which in an example stores all data for a structured, e.g. market_locale_pagetype_group-name, combination. A second step is to generate URLs via a Uniform Resource Locator (URL) management system (UMS) and for example to convert related csv files into json files to store (e.g. in s3) ready to be uploaded to the data store. For Ingestion, a (e.g. manually) triggered process is used that reads new link data, updates the data store and link state, and maintains the previous link state. For Storage, Storage is provided in the database (e.g. DynamoDB), with link groups as children of a page instance item. Page instances can store link groups generated inhouse and by external suppliers (e.g. agencies) side by side. For delivery, the solution is served via a unified link-service endpoint.

[0193] Summary of Steps in an Example System and Method for Internal Linking Core Infrastructure

[0194] Step One: Generate Raw Data

[0195] In an example there are two sources of raw link data, in-house and external e.g. agency. A pipeline is provided for producing links in-house. The output is files containing groups of links to be displayed on different page instances. External parties (e.g. agencies) may provide pre-generated urls; the internal in-house process may produce UMS parameters.

[0196] An example data format for in-house links is comma-separated values (CSV) files with the naming convention:

[0197] {market} / {locale} / {donor_page_type} / {group_name} / {partition_id} .csv e.g. uk / en-gb / flights-to-city-airport / flights-to-country / {partition_id} .

[0198] Here, the Csv file contains links to flights-to-country pages to be displayed on the flights to city airport pages in the uk market.

[0199] Example file contents are: donor_page_params, country code country _code=uk, de country _code=mx, fr country _code=uk, mx country _code=fr, us

[0200] The format of external (e.g. agency) data matches the structure we have chosen for our data model, but requires validation.

[0201] In an example, the files are json and the names are the encoded urls of the page the links are being displayed on.

[0202] Example file contents

[0203] {

[0204] "groups": [

[0205] {

[0206] "label" / 'Hotels",

[0207] "links": [

[0208] {

[0209] "url": "https: / / www.sky scanner.com / hotels / burkina-faso / ouagadougou- hotels / ci-27545264",

[0210] "keyword": "Book Hotel in Ouagadougou"

[0211] },

[0212] ]

[0213] },

[0214] {

[0215] }

[0216] ]

[0217] }

[0218] Step Two: Convert Raw Data into Ingestable Format

[0219] In an example, before ingesting updates into the data store, both internal and external data sets need some processing. Specifically:

[0220] • External (e.g. agency) data needs to be validated.

[0221] • In-house data needs to be converted from UMS parameters into URLs.

[0222] • Both sets of data may be written to dynamo json, i.e. in DynamoDB submitted in json, and / or stored in json.

[0223] • External (e.g. agency) data that fails validation will be returned to the external party (e.g. agency) with errors logged.

[0224] • In-house data that fails conversion generates alert(s) with errors logged.

[0225] Updates may be stored (e.g. in s3), e.g. with the timestamp of the data generation, e.g. as the prefix.

[0226] Step Three: Ingest Data Into Data Store

[0227] This step may be triggered (e.g. manually), and releases a new 'Link State' ingesting the update into the database (e.g. DynamoDB). A high level overview of an example process is:

[0228] 1) Trigger directed acyclic graph (DAG), passing in new version number and a timestamp matching the prefix (e.g. in s3) containing the update data

[0229] 2) Get update data (e.g. from s3)

[0230] 3) Identify relevant (e.g. {market}_{locale}_{page-type}) tables that are being updated (e.g. a table for each combination).

[0231] 4) Retrieve latest version of identified tables (e.g. from s3 store)

[0232] 5) Put updates to file

[0233] 6) Write (e.g. to s3) as new version (e.g. with timestamp as suffix)

[0234] 7) Import new files to database (e.g. DynamoDB) (e.g. using import from s3 functionality), creating a new table with the naming convention, e.g. {market}_{locale}_{page-type}_{timestamp}.

[0235] The files in the (e.g. s3) data store are in one-to-one (1 : 1) correspondence with a table in the database (e.g. DynamoDB). DAG may be connected to ETL as a process.

[0236] Step Four: Update Table Versions To keep track of the latest version of each table, a new version entry is created for each release in the versions metadata table. DyanmoDB uses Tables. Each Table has its own schema. It may be possible to batch import Tables into the database. Old Table versions may be stored in the database (e.g DyanmoDB).

[0237] An example process includes as follows:

[0238] 1) Retrieve latest version (e.g. j son blob, key:value)

[0239] 2) Put changes

[0240] 3) Add new version entry

[0241] In an example, the key value pairs in the version table are: uk_en-gb_routes-from-to: " 1664283071 "

[0242] Step Five: Use New Version in application programming interface (API)

[0243] The final step of the DAG is to propagate the latest iteration of the version metadata table to the link-service API, which is part of the backend. The final stage of the release process is a (e.g. manual) update to the configuration service. Two advantages from this part of the process are:

[0244] 1) Allows testing of the new internal link state before release

[0245] 2) Fast, easy rollback solution via the configuration service

[0246] The table response may be cached in the link-service to ensure we don't need to make two requests to the Link Store each time, reducing the response time of the API.

[0247] More detailed explanation of each step

[0248] Step One: Generate Raw Data

[0249] In an example, there are two sources of data for internal links: In-house and external (e.g. 3rd party). In an example, the data format is provided for in-house is csv files with a naming convention, e.g. including a dimensional structure, eg. : {market} / {locale} / {page_type} / {group_name} / {partition_id}.csv ({partition id} may define how data is stored, such as in separate data blocks.) Each file contains a list of parameters e.g. for a given market, locale, page type, group combination. These can be used in requests to the URL Management Service (UMS) to create into a usable link. These may be converted over to a particular file format and schema. This can be done by including an extract, transform, load (ETL) step in the flow to allow us to have the correct file format and data ready for the data store. More of this is explained in step two.

[0250] The external (e.g. 3rd party) data is provided in a consumable format but lacks meta data. It may be stored under the file name of the url. An example file is:

[0251] {

[0252] "groups": [

[0253] {

[0254] "label" / 'Hotels",

[0255] "links": [

[0256] {

[0257] "url": "https: / / www.sky scanner.com / hotels / burkina-faso / ouagadougou- hotels / ci-27545264",

[0258] "keyword": "Book Hotel in Ouagadougou"

[0259] },

[0260] ]

[0261] },

[0262] {

[0263] }

[0264] ]

[0265] }

[0266] An ETL task is provided to convert the data into the correct format and schema.

[0267] How does ETL work? Extract, transform, and load (ETL) works by moving data from the source system to the destination system, e.g. at periodic intervals. An example ETL process includes three steps:

[0268] 1) Extract the relevant data from the source database;

[0269] 2) Transform the data so that it is better suited for analytics;

[0270] 3) Load the data into the target database.

[0271] In an example of Step One, an in-house link pipeline provides links to a holding pen, which is a bucket containing CSV files with UMS parameters in. The holding pen provides data for the latest update of in-house generated links on the website. If the holding pen identifies failed jobs, these are sent back to the in-house link pipeline. A third party (e.g. agency) provides link data for the latest update of third party links on the website. Failed data is sent back to the third party (e.g. agency). An example is shown in Figure 2.

[0272] Step Two: Convert Raw Data into Ingestable Format

[0273] In an example, the link data may come from at least two sources, external (e.g. 3rd party) and in house. Data from both sources need to be extracted, transformed and pushed (e.g. into a S3 bucket) so it can be loaded into the datastore. In an example, the external (e.g. 3rd party) data is already in a consumable j son format, but does not contain any meta data link tab grouping and needs to be transformed. In an example, the in house solution is in a parameterized format which needs to call UMS to convert it into useful data. This means that we may need two additional ETL steps to push the data ready to be ingested in the data store.

[0274] The raw data from both the external (e.g. agencies) and in house solutions may be combined into an update to each page instance. This may include:

[0275] 1) Data validation - rules by which external (e.g. agency) data is either accepted for transformation or rejected. The data validation process is automated and runs as soon as new agency data is submitted. This means that external (e.g. agencies) receive rejected data straight away. 2) Internal linking state - a list of which recipient pages are linked to per donor page. The data stored (e.g. in S3) is the single source of truth for this, but it is served to clients of the link service via the database (e.g. DynamoDB). This may be versioned as described in stage four.

[0276] 3) Data transformation - the process by which data entries in the format described in the data definition are created from the raw data generated internally or by external parties (e.g. agencies).

[0277] Each source may have its own ETL that loads data into an updates bucket. This may be a one to one mapping of a page instance's table. This allows in later stages for the tables of a given page instance to be overwritten.

[0278] In an example of Step Two, a trigger with market-page-type-locale combinations to release new versions for, or “sitemaps”, is received by a DAG process. Anchor text (e.g. provided by a SEO group) may be added to the DAG process output, then using the data corresponding to in-house links, UMS parameters are converted into URLs to create link groups, which are passed to an internal linking store, which contains the latest update data. Received third party (e.g. agency) links are validated, and if the validation fails, the failed data may be put into a validation bucket and then sent back to the third party (e.g. agency). When the received third party (e.g. agency) links are validated, if the validation succeeds, link data is sent to the internal linking store, which contains the latest update data. An example is shown in Figure 3.

[0279] Step Three: Ingest Data Into Data Store

[0280] Once the update data is put into the (e.g. S3) internal linking store, it is held there until a new link orchestration is triggered (e.g. by a SEO team). A trigger can be pushed (e.g. by a SEO team), which then starts a batch job pushing the update data (e.g. to another bucket) which has a one-to-one (1 : 1) mapping of the database (e.g. DynamoDB) datastore. This data can then be directly imported into the database (e.g. DynamoDB) using the import feature. The data (e.g. from the updates bucket) needs to be transformed e.g. into the one-to-one (1 : 1) bucket.

[0281] The database (e.g. DynamoDB) may be chosen according to: • Faster read times preferred - The database backend will be queried multiple times a second, and any delay would affect website (e.g. Skyscanner) customer experience negatively.

[0282] • Intuitive implementation of data definition - For developer experience, the easier the schema is to understand the better

[0283] • A managed service - a standard practice may be that a squad (e.g. technical SEO) will manage the link-service. Any additional effort saved by using an (e.g. Amazon Web Services, Inc. (AWS)) managed solution allows the squad to dedicate more resources to other technical SEO work.

[0284] • Being cost effective.

[0285] The use of a database (e.g. DynamoDB) can be summarised in the following points):

[0286] • Programmatic interaction may be achieved using boto3 library in python, where boto3 is a standard library in python.

[0287] • All reads from the link-service may be single item look-ups by URL, for example because a single link may be used. The schema may have a simple primary key of the URL partition key only; use of a partition key relates to the size of the accessed stored data. For the example of a DynamoDB database, Getltem is the most efficient way of getting a single item of data. The API may use a query similar to the following example, where “Key” relates to a partition key:

[0288] {

[0289] TableName: "{market}_{page-type}_{locale}_{timestamp}",

[0290] Key: {

[0291] "URL": "{donor-url}"

[0292] }

[0293] }

[0294] • The link-state is stored in (e.g. in S3) link-data-store in e.g. JSON or Amazon ION (a superset of JSON that is binary encodable) format after raw data is transformed and ingested.

[0295] • The link-data-store data structure is a one to one mapping with tables in the database (e.g. DynamoDB) e.g. uk / en-gb / routes-from -to / 166428307 l.j son contains the data for table uk_routes-from-to_en-GB_l 664283071.

[0296] • A separate table of versions that sets which tables should be used for a given version allows updating and rollback of link state. See Data Versioning section for more example details.

[0297] In an example, the following database (e.g. DynamoDB) data schema has been chosen:

[0298] Table name: The table name is made up of:

[0299] <market>-<locale>-<page_type>-<timestamp>

[0300] Where: market: Market of the page instance locale: Locale of the page instance page type: Page type of the page instance timestamp: timestamp that the ingestion job started for that given ingestion. This allows versioning to be adapted.

[0301] Schema

[0302] An attribute is Page Instance URL (Partition key), and the Type is String.

[0303] An attribute is Groups, and the Type is Array of Group.

[0304] Group

[0305] An attribute is Group Text, and the Type is String.

[0306] An attribute is Links, and the Type is Array of Link.

[0307] Link

[0308] An attribute is url, and the Type is String

[0309] An attribute is link text, and the Type is String

[0310] An attribute is section text, and the Type is String

[0311] An attribute is denormalised parameters, and the Type is Key / value pairs of parameters for placeholders.

[0312] In an example of Step Three, the latest update data is received from the internal linking store, updates are put to a (e.g. s3) store, then data is imported to update into new tables. An example filename is uk / en-gb / routes-from-to / {timestamp}.json. The internal linking store contains data mapping to tables in DynamoDB one-to-one. This data is then automatically ingested to DynamoDB, to a new DynamoDB table, of which an example is uk_en-gb_routes-from-to_l 664283452. A process may be triggered with a version number and timestamp, and then an internal link orchestrator may carry out the process including updates being put to the (e.g. s3) store, then data being imported to update new tables, and data being automatically ingested to DynamoDB, to the new DynamoDB table. An example is shown in Figure 4.

[0313] Step Four: Update Table Versions

[0314] In an example, upload of Tables is performed using a single instruction. This is an advantage over updating links individually, which requires many instructions to update many data elements. A new Table is retained for each respective Table update. A (e.g. S3) update is a low cost way of importing bulk data. This limits storage use, since only new Tables need to be stored for each bulk update. Some recent versions of old Tables (e.g. 2 or less, 3 or less, 5 or less, or 10 or less) may be retained, and other versions of old Tables may be deleted. Creating a new Table is cheaper than modifying an old Table, because modifying an old Table requires many instructions to update many data elements.

[0315] In an example, data for internal links can come from multiple internal and external (e.g. 3rd party) sources. Because of this, it may be desired (e.g. by a SEO team) to test and rollback links if a new set of internal links does not provide the intended results, to allow issues to be fixed. To this end, the stack has been designed with version and rollback in mind. Once the data has gone through the pipeline, the ingestion buckets data for each batch into timestamp tables. Then the latest table is saved for a given market-locale-page type in a look up table. This may work by:

[0316] • Query the configuration service with key for current version. This will return the current version.

[0317] Query the cached local version mapper for the timestamp data. The local version is updated (e.g. by a worker) in the api, which synchronizes with a S3 bucket with version map.

[0318] • Query the datastore with the page instances url and table name joined with the timestamp ( e.g. <market>-<locale>-<page_type>-<timestamp>). Return a list of links for a given page instance.

[0319] This allows us to solve two different problems: release and rollback.

[0320] While data is ingested, the release of that data may be staggered. This may happen in two stages. The first is a (e.g. manual) trigger to take data in internal linking store and push it to the database (e.g DynamoDB). This allows (e.g. the SEO team) to control when new links are displayed on landing pages by creating a new version every time the trigger is activated. Then a (e.g. SEO) team can use an override to view these changes before they are released. This is helpful as it allows the team to validate changes. Then if the team is not content with a change, they can roll back to a previous version, and then make changes with data sources and perform the process again. In an example, a cleaning service is provided, that cleans (e.g. deletes) old versions of data, e.g. therefore only keeping a subset of the previous data, e.g. around three versions of previous data, or e.g. less than five or less than ten versions of previous data.

[0321] In an example of Step Four, data from a new DynamoDB table is used to put updates to a latest version table. The Internal Link Orchestrator may carry out this process so that a latest versions bucket contains the updates put to the latest version table. The latest bucket version can be fetched in a thread. In an example, retrieval is performed of the previous version, which adds / overwrites with the new table versions. A format for version metadata is a key value pair. A nested map of <table_name>:<timestamp> may be nested under a version number (e.g. vl, v2). Versions may be immutable. An example is:

[0322] {

[0323] “vl”:{

[0324] “uk-en_gb-routes_from_to” : 1664958426, “v2”:{

[0325] “uk-en_gb-routes_from_to” : 1665134826,

[0326] },

[0327] An example of Step Four is shown in Figure 5.

[0328] Step Five: Use New Version in application programming interface (API)

[0329] In an example, the API is part of the backend, in the deep backend. The backend is in connection with the front end. The API makes links available to the front end.

[0330] Firstly, lets describe an example of the API. The API allows frontend services to be served links from the data store. An endpoint is provided such that a deprecation of an original endpoint can be done. The provided endpoint may follow the sequence as per the example of Figure 6.

[0331] The api may have a / v2 / links gRPC endpoint. gRPC (gRPC Remote Procedure Calls) is a cross-platform high performance remote procedure call (RPC) framework.

[0332] An example request body may contain:

[0333] If the Name is url, then the Type is String, and the description is the url of a given page instance that a link is being called for.

[0334] If the Name is market, then the Type is String, and the description is e.g. UK. This may map to a (e.g. Skyscanner) TLD such as Skyscanner.net.

[0335] If the Name is locale, then the Type is String, and the description is e.g. en gb. The locale of the page.

[0336] If the Name is locale, page type, then the Type is String and the description is e.g. routes from to The SEO page type.

[0337] If the Name is version, then the Type is optional int, and the description is version of the data, allows testing and backwards compatibility.

[0338] In proto format:

[0339] A Request Example is: syntax = "proto3" message LinksRequest { string url = 1 ; string market = 2; string locale = 3; string page_type = 4; int version = 5; / / optional

[0340] }

[0341] Where the response would be an array of groups, for example as described below:

[0342] If the Name is group text, then the Type is String, and the description is Placeholder for group text.

[0343] If the Name is links, then the Type is Array, and the description is an array of link data (see below).

[0344] Link

[0345] If the Name is url, then the Type is String, and the description is url to page instance for the given link.

[0346] If the Name is link text, then the Type is String, and the description is Place holder text for hyperlink text.

[0347] If the Name is section text, then the Type is String, and the description is Place holder text for section title text.

[0348] If the Name is parameters, then the Type is String, and the description is key value map of values for placeholders. In proto format:

[0349] A Response Example is: syntax = "proto3" message LinksResponse { repeated Group groups = 1;

[0350] } message Group { string group_text = 1 ; repeated Link links = 2;

[0351] } message Link { string url = 1 ; string link_text = 2; map<string, string> parameters = 3; string section_text = 4; / / optional

[0352] }

[0353] When the gRPC endpoint receives a request, it will or it may:

[0354] 1. Check the configuration service for the most recent version if no version specified in request

[0355] 2. Get the table name for the market_locale_page-type combination

[0356] 3. Use Java Amazon Web Services (AWS) software development kit (SDK) v2 to build a query that will get item with corresponding from that table

[0357] 4. Package a gRPC response according to the schema defined above and send it to the client.

[0358] In an example of Step Five, the Link Service API may fetch the latest bucket version in a thread. In an example, retrieval is performed of the previous version, which adds / overwrites with the changed table versions. The Link Service API may use a locally stored version table to get the correct table from the Link Store. The Link Service API may receive input from a microsite / component, for frontend integration. The Link Service API may query a configuration service about which version should be used. The configuration service sets which link state version to use (e.g. set by SEO group). The SEO group can test the output of latest version using query parameters. An example is shown in Figure 6.

[0359] Example Data Definition & Model

[0360] Example Data Definition

[0361] To allow the front end to create cross linking on its pages, a data definition is used which allows us to serve this use case. This includes page instances and links.

[0362] Page instance

[0363] A page instance is a single landing page for the (e.g. Skyscanner) website which is served e.g. by Falcon. (Falcon is a Python web framework designed for building fast Representational state transfer (REST)-ful APIs with minimal external dependencies). This contains the metadata about the page:

[0364] • Market - The market for the given page.

[0365] • Locale - The locale (language) a given page.

[0366] • URL - the canonical URL of the given page.

[0367] • Page type - The page type a given page.

[0368] Link

[0369] On a given page, there are a number of links, which are linked to other page instances. These contain metadata of

[0370] • Group - The name of the group (or tab) which the link belongs to.

[0371] • Link Text - The hyperlink text for a given link.

[0372] • Section - The section title text the link belongs to.

[0373] • Page type - The page type of a given page.

[0374] • Denormalised Paramaters - Parameters to fill data in placeholder text.

[0375] With the data above, we create a highly read optimised solution that has a low write cadence. This means that we are unconcerned with space efficiency or redundant data. With this in mind, we create the following data definition for the database (e.g. DynamoDB).

[0376] Data Model

[0377] Table name

[0378] <market>-<locale>-<page_type>-<timestamp>

[0379] Where:

[0380] • market: Market of the page instance

[0381] • locale: Locale of the page instance

[0382] • page type: Page type of the page instance

[0383] • timestamp: timestamp that the ingestion job started for that given ingestion. This allows versioning to be adapted.

[0384] Schema

[0385] If the Partition Key is Page Instance URL, then the Attributes are Groups.

[0386] If the Partition Key is String, then the Attributes are Array of Group.

[0387] Group

[0388] If the Attribute is Group Text, then the Type is String.

[0389] If the Attribute is Links, then the Type is Array of Link.

[0390] Link

[0391] If the Attribute is url, then the Type is String

[0392] If the Attribute is link text, then the Type is String

[0393] If the Attribute is section text, then the Type is String

[0394] If the Attribute is denormalised parameters, then the Type is Map of any parameters.

[0395] Data Store

[0396] In an example, during the decisioning process, several constraints are set that inform which database backend is used for the link-service: • Faster read times preferred - The database backend is queried multiple times a second, and any delay would effect website (e.g. Skyscanner) customer experience negatively.

[0397] • Intuitive implementation of data definition - For developer experience, the easier the schema is to understand, the better.

[0398] • A managed service - A team manages the link-service.

[0399] • Cost effective.

[0400] Though several database solutions are possible, DynamoDB and Aurora RDS were the two main contenders. The schema in DynamoDB maps more intuitively to the raw JSON link data, and look-up by URL may be built into the solution by making URL the partition key.

[0401] The use of DynamoDB can be summarised in the following points:

[0402] • Programmatic interaction may be achieved using boto3 library in python.

[0403] • All reads from the link-service may be single item look-ups by URL. The schema has a simple primary key of the URL partition key only. Getltem is typically the most efficient way of getting a single item of data. The API may use a query similar to the following example:

[0404] {

[0405] TableName: "{market}_{page-type}_{locale}_{datetime-created}",

[0406] Key: {

[0407] "URL": "{donor-url}"

[0408] }

[0409] }

[0410] • In an example, the link-state is stored in (e.g. S3) link-data-store in JSON or Amazon ION (a superset of JSON that is binary encodable) format after raw data is transformed and ingested.

[0411] • The link-data-store data structure may be a one to one mapping with tables in DynamoDB e.g. uk / en-gb / routes-from -to / 166428307 l.j son contains the data for table uk_routes-from-to_en-GB_l 664283071. • A separate table of versions that sets which tables should be used for a given version allow updating and rollback of link state. See Data Versioning section for more example details.

[0412] With the above points in mind, the design of the API may have the following sequence of requests and responses between the different services:

[0413] Data Ingestion

[0414] Example Important concepts for data ingestion include

[0415] • Raw data - the data generated externally (e.g. by agencies) or internally

[0416] • Data validation - rules by which external (e.g. agency) data is either accepted for transformation or rejected. The data validation process is automated and runs as soon as new external (e.g. agency) data is submitted. This means that external party (e.g. agency) sees rejected data straight away.

[0417] • Internal linking state - a list of which recipient pages are linked to per donor page. The data stored (e.g. in S3) is the single source of truth for this, but it is served to clients of the link service via database e.g. DynamoDB. This may be versioned as described in the version control section.

[0418] • Data transformation - the process by which data entries in the format described in the data definition are created from the raw data generated internally or externally (e.g. by agencies).

[0419] • DynamoDB Ingestible formats - The internal linking state is stored (e.g. in S3) in one of the following formats:

[0420] CSV - Suitable if all data is in string format and the data structure is flat. Not used for link data as we have a nested data schema.

[0421] DynamoDB JSON - Similar to a standard JSON dictionary but values are replaced with {key: value} objects where the key is the type.

[0422] Amazon ION - A richly typed superset of JSON that is also binary encodable for compression

[0423] • DynamoDB - The link service backend DB described in the data store section.

[0424] When new data is created externally (e.g. by agencies) it may be stored in a “holding pen” bucket. Once a new internal linking state is ready to be created, a DAG wrapping an AWS batch job may be (e.g. manually) triggered that will begin transforming the data into the structure in the data definition and storing it in a database (e.g. Dynamo DB) ingestible format. The (e.g. manual) trigger is part of the original requirements. An automated process that runs every time new link data is available would make versioned link state impractical. Typically, a batch job is used rather than a lambda because of the volume of data (lambda's are time limited and more suitable for smaller compute constrained jobs rather than data constrained ones). The files from this may have a filename market page-type locale timestamp that corresponds directly to a table in the database (e.g. DynamoDB). Once all these files have been written to (e.g. the S3 part of) the data store, the database (e.g. DynamoDB) tables will be updated. The update to database (e.g. DynamoDB) tables may be as follows:

[0425] 1) For each new file 'market_page-type_locale_timestamp' written (e.g. to S3), ingest the file into the link-data database (e.g. DynamoDB) instance as a new table with the same name as the file.

[0426] 2) Add a new version to the version database (e.g. DynamoDB) that is a copy of the previous version except for tables with the updated prefix ' market _pagetype_ locale' . In the new version entry, these will have the updated timestamp suffix instead.

[0427] 3) If we wish to start using the new version right away, the config store is updated so that “current link state version” stores the newly added version identifier.

[0428] It may be a requirement of this design that external (e.g. agency) data contains at least the minimum amount of data required in the data definition. (AWS Lambda is a serverless, event-driven compute service that permits running code for a broad set of types of application or backend service without provisioning or managing servers. Lambda can be triggered from over 200 AWS services and software as a service (SaaS) applications).

[0429] Migration The system provides at the API level two functions, one for getting the count of total links on a page and one for getting links by donor URL.

[0430] For the functional area API, the end point returns link data in the new structure. Link count is available.

[0431] For the functional area TRANSFORMATION OF LINK DATA, UMS parameters may be used to generate URLs in a DAG process. An external party (e.g. agency) provides data.

[0432] For the functional area STORAGE OF LINK DATA, data state is stored (e.g. in S3) with all links mapped to donor URLs. A database (e.g,. DynamoDB) ingestable format may be used.

[0433] For the functional area VERSIONING, link state is versioned. Version of link state served by API is configurable, so rollbacks are possible.

[0434] The system and method allow us to more effectively use storage space which is cheap, instead of read times and computing resources which are more expensive.

[0435] This is achieved by storing the data in a format that has the links associated with a URL already expanded and ready to be served from the database (e.g. DynamoDB) instance. In the design, versioning may be present.

[0436] A migration from previous data formats may be performed with a one off batch job that runs the transformation routines.

[0437] Example Language and Frameworks

[0438] Java may be used for link service API, and python may be used in the AWS batch jobs. Both languages have a rich ecosystem of AWS integrations.

[0439] AWS batch jobs may be used because they perform better than lambdas or other similar technologies for potentially long running tasks. These jobs may be wrapped in DAGs.

[0440] Metrics and Logging

[0441] New Relic (supplied by New Relic, Inc., 188 Spear St, Suite 1000, San Francisco, CA, USA 94105) may be used to log:

[0442] • Rejected links - Log source and reason for rejection. These logs may be used to discern if rejected links have since been updated and resubmitted.

[0443] • When a new version is released

[0444] • Creation, ingestion, and deletion of mapping tables

[0445] • When latest versions are fetched by link service API

[0446] • Unsuccessful queries to API and reason therefor.

[0447] • Updates to version table, e.g. to make sure these only happen when (e.g. manual) version update is triggered.

[0448] Deployment

[0449] The deployment of the service may include three parts:

[0450] • Data ingestion side may be deployed by using (e.g. apache Airflow) to create batch jobs.

[0451] • Database (e.g. DynamoDB) may be deployed using cloudformation.

[0452] • The api may be deployed in a Kubemetes infrastructure.

[0453] All deployments may be started from merging of pull requests in GitHub.

[0454] Data pipeline

[0455] The data pipeline may be deployed by creating a new batch job (e.g. in Apache Airflow). This may be done by uploading a container image e.g. to Amazon Elastic Container Registry (AWS ECR) and running a batch job with that image using the normal deployment for (e.g. Skyscanner) Airflow. This may only need to be in a single geographic region to push to a primary database.

[0456] Database and object storage (e.g. DynamoDB & S3)

[0457] The Database (e.g. DynamoDB) datastore and object storage (e.g. S3) may be deployed e.g. using AWS CloudFormation. The Database (e.g. DynamoDB) instances may be multi region with multiple AZ zones for redundancy. It may be that one region holds the primary database which will then push using Synchronous Replication to read replicas.

[0458] API

[0459] The api may be deployed using Github Actions and slingshot and may be manifested to Kubernetes (k8s) in website (e.g. Skyscanner) infrastructure (Kubemetes is an open-source container orchestration system for automating software deployment, scaling, and management). This may be multi region to allow faster request times in different geographic regions.

[0460] Monitoring and Alerting

[0461] In an example, New Relic is used. Alerts are generated for example when:

[0462] • 500 errors occur.

[0463] • No table is found for market locale _page-type

[0464] • A request takes longer than baseline time.

[0465] Amazon S3 or Amazon Simple Storage Service

[0466] Amazon S3, or Amazon Simple Storage Service, is a service offered by Amazon Web Services (AWS) that provides object storage through a web service interface. Amazon S3 uses the same scalable storage infrastructure that Amazon.com uses to run its e- commerce network. Amazon S3 can store any type of object, which allows uses like storage for Internet applications, backups, disaster recovery, data archives, data lakes for analytics, and hybrid cloud storage. AWS launched Amazon S3 in the United States on March 14, 2006, then in Europe in November 2007.

[0467] Amazon DynamoDB

[0468] Amazon DynamoDB is a fully managed proprietary NoSQL database service that supports key-value and document data structures and is offered by Amazon.com as part of the Amazon Web Services portfolio. DynamoDB uses synchronous replication across multiple data centers for high durability and availability. DynamoDB was announced by Amazon CTO Werner Vogels on January 18, 2012, and is presented as an evolution of Amazon SimpleDB. A NoSQL (originally referring to "non-SQL" or "non-relational") database provides a mechanism for storage and retrieval of data that is modeled using relations other than the tabular relations used in relational databases.

[0469] JSON (JavaScript Object Notation)

[0470] JSON (JavaScript Object Notation) is an open standard file format and data interchange format that uses human -readable text to store and transmit data objects consisting of attribute-value pairs and arrays (or other serializable values). It is a common data format with diverse uses in electronic data interchange, including that of web applications with servers.

[0471] JSON is a language-independent data format. It was derived from JavaScript, but many modern programming languages include code to generate and parse JSON- format data. JSON filenames use the extension .json.

[0472] Amazon Ion

[0473] Amazon Ion is a data serialization language developed by Amazon. It may be represented by either a human-readable text form or a compact binary form. The text form is a superset of JSON; thus, any valid JSON document is also a valid Ion document.

[0474] Representational state transfer (REST)

[0475] Representational state transfer (REST) is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of an Internet-scale distributed hypermedia system, such as the Web, should behave. The REST architectural style emphasises the scalability of interactions between components, uniform interfaces, independent deployment of components, and the creation of a layered architecture to facilitate caching of components to reduce user-perceived latency, enforce security, and encapsulate legacy systems. REST has been employed throughout the software industry and is a widely accepted set of guidelines for creating stateless, reliable web APIs. A web API that obeys the REST constraints is informally described as RESTful. RESTful web APIs are typically loosely based on HTTP methods to access resources via URL-encoded parameters and the use of JSON or XML to transmit data.

[0476] Note

[0477] It is to be understood that the above-referenced arrangements are only illustrative of the application for the principles of the present invention. Numerous modifications and alternative arrangements can be devised without departing from the spirit and scope of the present invention. While the present invention has been shown in the drawings and fully described above with particularity and detail in connection with what is presently deemed to be the most practical and preferred example(s) of the invention, it will be apparent to those of ordinary skill in the art that numerous modifications can be made without departing from the principles and concepts of the invention as set forth herein.

Claims

CLAIMS1. A computer-implemented method of updating links in a website backend with updated links, wherein the updated links in the website backend are made available to a website frontend in communication with the website backend, the method including the steps of:(i) storing or accessing a multi-dimensional data structure, comprising at least two dimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multi-dimensional data structure;(ii) receiving update link data including parameters, and using the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;(iii) putting the updated data receiving elements into a data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;(iv) storing new database tables using the data mapping the updated data receiving elements in the data store to the database tables, and ingesting the new database tables to a database, and recording the ingested new database tables in a table of latest versions;(v) using the table of latest versions to obtain latest database tables from the database, and updating the links in the website backend using the latest database tables from the database, and(vi) the website backend making available the updated links in the website backend to the website front end, in which the website frontend is in communication with the website backend.

2. The method of Claim 1, wherein the website is a website for travel services.

3. The method of Claim 2, wherein the travel services include flights, or hotel reservations, or car hire.

4. The method of any previous Claim, wherein the parameters define which links appear on which donor website page or pages.

5. The method of any previous Claim, wherein the backend includes page instances, in which each page instance includes metadata relating to the page, including data relating to an address, or to a group of addresses, associated with the page, in the multi-dimensional data structure, the backend using page instances and links included in database tables relating to the address, or to the group of addresses, to provide web pages to the front end.

6. The method of Claim 5, wherein a respective page instance item includes respective links generated by the website owner and respective links generated by a third party.

7. The method of Claims 5 or 6, wherein database tables are stored in the database (e.g. DynamoDB), the database tables including page instance items.

8. The method of any of Claims 5 to 7, wherein link groups are children within a respective page instance item.

9. The method of any of Claims 5 to 8, wherein respective groups of links are associated with respective webpage instances.

10. The method of any of Claims 5 to 9, wherein the received update link data includes a respective update for respective page instances.

11. The method of any previous Claim, wherein the new database tables are stored in a format in which links associated with a URL are ready to be served from the database.

12. The method of any previous Claim, including the step of: (vii) the website frontend serving first updated links of the updated links in webpage content of a webpage, responsive to a request for the webpage.

13. The method of any previous Claim, including updating links in principal web pages of the website, e.g. search engine optimization (SEO) landing pages.

14. The method of any previous Claim, wherein the update link data includes links generated by the website owner and includes links generated by third parties.

15. The method of any previous Claim, wherein ingesting the new database tables to the database is performed using a single instruction.

16. The method of any previous Claim, wherein a new Table is stored or retained for each respective Table update.

17. The method of any previous Claim, wherein recent versions of old Tables (e.g. 2 or less, 3 or less, 5 or less, or 10 or less) are stored or retained, and other versions of old Tables are deleted.

18. The method of any previous Claim, wherein only new Tables are stored for each bulk update of Tables.

19. The method of any previous Claim, including a step of the database serving a previous version of a database table, in response to an instruction to serve the previous version of the database table.

20. The method of any previous Claim, including a step of the database serving a previous version of a set of database tables, in response to an instruction to serve the previous version of the set of database tables.

21. The method of any previous Claim, in which previous database tables are stored in the database with a corresponding version identifier, and the method includes the step of rolling back the links at the website backend to use the links in the previous database tables that are stored in the database with the corresponding version identifier.

22. The method of any previous Claim, wherein database tables in the database include a version identifier.

23. The method of Claim 22, wherein database tables in the database include a version identifier, and database tables corresponding to a particular identifier are accessible for review / analysis using the particular identifier.

24. The method of Claim 22, wherein database tables in the database include a version identifier, and database tables corresponding to a particular identifier are exportable for review / analysis using the particular identifier.

25. The method of any previous Claim, wherein updating the links in the website backend using the latest database tables from the database includes updating at least one thousand links, or at least ten thousand links, or at least one hundred thousand links.

26. The method of any previous Claim, wherein updating the links in the website backend using the latest database tables from the database includes updating at least one million links.

27. The method of any previous Claim, wherein updating the links in the website backend using the latest database tables from the database includes updating at least two million links.

28. The method of any previous Claim, wherein the new database tables may only be ingested to the database, when a corresponding version identifier has been created and is used to identify uniquely the new database tables.

29. The method of any previous Claim, wherein after the new database tables are ingested to the database, the new database tables may not be changed until further new database tables are ingested to the database.

30. The method of any previous Claim, wherein steps (i) to (iv) include:(a) Triggering a directed acyclic graph (DAG), including a new version number;(b) Getting the link update data;(c) Identifying relevant tables that are being updated;(d) Retrieving a latest version of the identified tables;(e) Putting the link updates to the retrieved latest version of the identified tables;(f) Writing the results of step (e) as a new version;(g) Importing files of the new version to a database, to create a new table in the database.

31. The method of any previous Claim, wherein in step (iv), tables are batch imported into the database, e.g using python.

32. The method of any previous Claim, wherein each table has its own schema.

33. The method of any previous Claim, wherein old table versions are stored in the database.

34. The method of any previous Claim, wherein in step (v), the latest iteration of a version metadata table is propagated to a link-service API, which is part of the backend.

35. The method of Claim 34, wherein the link-service API makes links available to the front end.

36. The method of Claims 34 or 35, wherein the link-service API uses Java.

37. The method of any of Claims 34 to 36, wherein the link-service API is a backend API which uses a locally stored version table to retrieve the correct table from the database.

38. The method of any of Claims 34 to 37, wherein the link-service API is a backend API which receives input from a microsite or from a component, for frontend integration.

39. The method of any of Claims 34 to 38, wherein the link-service API is a backend API which queries a configuration service to determine which version of database tables should be used.

40. The method of any of Claims 34 to 36, wherein the link-service API is a backend API, wherein a version of a link state served by the backend API is configurable.

41. The method of any previous Claim, wherein the received update link data includes a list of which recipient pages are linked to per donor page.

42. The method of any previous Claim, wherein in step (v), updating the links in the website backend comprise single item look-ups by URL.

43. The method of any previous Claim, wherein the table of latest versions of step (iv) is a separate table of versions that is stored and which sets which tables should be used for a given version.

44. The method of any previous Claim, wherein when data is ingested, the release of that data is staggered, in two stages; the first stage is a trigger to take data in the internal linking store and push it to the database; then an approval is received before the changes are released.

45. The method of any previous Claim, wherein retrieval is performed of the previous table versions, in which the new table versions are added to, or overwrite, the previous table versions.

46. The method of any previous Claim, wherein table versions are immutable.

47. The method of any previous Claim, wherein the multi-dimensional data structure includes a {market} / {locale} / {page_type} structure.

48. The method of any previous Claim, wherein externally created link data is stored in a bucket, and then a DAG is triggered to transform the link data stored in the bucket into a structure suitable for ingestion into the database.

49. The method of Claim 48, wherein a batch job is used to transform the link data stored in the bucket into the structure suitable for ingestion into the database, eg. using python.

50. The method of any previous Claim, wherein step (iv) includes adding a new version to the table of latest versions, wherein the new version is a copy of the previous version except for the new database tables.

51. The method of any previous Claim, wherein a configuration service stores data identifying which version is a current version.

52. The method of Claim 51, wherein the configuration service records which version of the ingested database tables is currently in use.

53. The method of any previous Claim, wherein the ingested database tables currently in use are testable using query parameters.

54. The method of any previous Claim, wherein a version is queryable to provide the count of total links.

55. The method of any previous Claim, wherein a version is queryable to provide the count of total links on a specified web page.

56. The method of any previous Claim, wherein a version is queryable to provide links by donor URL.

57. The method of any previous Claim, wherein the database is stored in database instances which are multi region.

58. The method of Claim 57, wherein one region holds the primary database which is then pushed using synchronous replication to read replicas for other regions.

59. The method of any previous Claim, wherein update link data is validated.

60. The method of Claim 59, wherein the update link data is validated to ensure that web pages do not link to themselves.

61. The method of Claims 59 or 60, wherein the update link data is validated to ensure that Links contained on a donor page all share the same top level domain (TLD) as the donor page itself.

62. The method of any of Claims 59 to 61, wherein the update link data is validated to ensure any link can only appear once on a donor page.

63. The method of any of Claims 59 to 62, wherein the update link data is validated to check the recipient page pointed to by the link is valid.

64. The method of any of Claims 59 to 63, wherein link validity is cached.

65. The method of any of Claims 59 to 64, wherein update link data which fails validation is notified to an originator of the update link data.

66. The method of any previous Claim, wherein update link data includes a configurable anchor text field.

67. The method of any previous Claim, wherein update link data includes a tab group field.

68. The method of any previous Claim, wherein update link data is such that aninternal linking state for a hostname remains the same once all pages for that hostname are generated.

69. The method of any previous Claim, wherein the database is served via a unified link-service endpoint.

70. The method of any previous Claim, wherein the update link data is in csv files.

71. The method of any previous Claim, wherein the datastore format includes j son or includes j son compatibility.

72. The method of any previous Claim, wherein the links are internal links.

73. A system including a website back end, a website front end, and a link updater in communication with the website backend, the link updater including a data store, a database and a table of latest versions, the system configured to update links in the website backend with updated links, wherein the updated links in the website backend are made available to the website frontend in communication with the website backend, wherein(i) the link updater is configured to store or to access a multi-dimensional data structure, comprising at least two dimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multi-dimensional data structure;(ii) the link updater is configured to receive update link data including parameters, and to use the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;(iii) the link updater is configured to put the updated data receiving elements into the data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;(iv) the link updater is configured to store new database tables using the data mapping the updated data receiving elements in the data store to the database tables,and to ingest the new database tables to the database, and to record the ingested new database tables in the table of latest versions;(v) the link updater is configured to use the table of latest versions to obtain latest database tables from the database, and to update the links in the website backend using the latest database tables from the database, and(vi) the website backend is configured to make available the updated links in the website backend to the website front end.

74. The system of Claim 73, configured to perform a method of any of Claims 1 to 72.

75. The link updater of the system of Claims 73 or 74.

76. A computer-implemented method of updating links in a website backend with updated links, the method including the steps of:(i) storing or accessing a multi-dimensional data structure, comprising at least two dimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multi-dimensional data structure;(ii) receiving update link data including parameters, and using the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;(iii) putting the updated data receiving elements into a data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;(iv) storing new database tables using the data mapping the updated data receiving elements in the data store to the database tables, and ingesting the new database tables to a database, and recording the ingested new database tables in a table of latest versions;(v) using the table of latest versions to obtain latest database tables from the database, and updating the links in the website backend using the latest database tables from the database.

77. The method of Claim 76, further including a method of any of Claims 1 to 72.

78. A computer program product executable on a processor to:(i) store or access a multi-dimensional data structure, comprising at least two dimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multidimensional data structure;(ii) receive update link data including parameters, and use the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;(iii) put the updated data receiving elements into a data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;(iv) store new database tables using the data mapping the updated data receiving elements in the data store to the database tables, and ingest the new database tables to a database, and record the ingested new database tables in a table of latest versions;(v) use the table of latest versions to obtain latest database tables from the database, and update links in a website backend using the latest database tables from the database.

79. Computer program product of Claim 78, executable on the processor to perform a method of Claims 76 or 77.

80. A computer including a computer program product of Claims 78 or 79, the computer further including a processor, wherein the computer program product is executable on the processor.

81. A link updater computer system, the link updater computer system including a processor, a data store, a database and a table of latest versions, the link updater computer system configured to:(i) store or access a multi-dimensional data structure, comprising at least twodimensions, the multi-dimensional data structure including data receiving elements, each data receiving element uniquely identified by a respective address in the multidimensional data structure;(ii) receive update link data including parameters, and use the parameters to enter groups of links into the data receiving elements to produce updated data receiving elements;(iii) put the updated data receiving elements into the data store, in a data store format, the data store including data mapping the updated data receiving elements in the data store to database tables, wherein the database tables are in one-to-one correspondence with the updated data receiving elements in the data store;(iv) store new database tables using the data mapping the updated data receiving elements in the data store to the database tables, and ingest the new database tables to the database, and record the ingested new database tables in the table of latest versions;(v) use the table of latest versions to obtain latest database tables from the database, and update links in a website backend using the latest database tables from the database.

82. The link updater computer system of Claim 81, configured to perform a method of any of Claims 1 to 72.

Images